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EXECUTIVE  SUMMARY 


This  report  covers  Task  C,  "Analyze  the  accuracy  and  timeliness  of 
available  data  used  in  the  current  LOGSACS  and  PERSACS"  of  a study 
to  determine  requirements  for  an  On-Line  Structure  and  Composition 
System  (SACS). 

The  basis  for  evaluating  timeliness  and  accuracy  of  the  SACS  pro- 
ducts were: 

• Produce  SACS  products  in  time  to  influence  current 
day-to-day  decisions. 

• Produce  SACS  products  containing  complete  unit, 
personnel,  and  equipment  data  for  a specific  "as  of" 
date  that  are  100%  accurate  in  representing  the 
Master  Force  as  selected  by  the  SACS  criteria. 

Section  3 and  the  appendices  of  the  report  identify  a number  of 
specific  timeliness  and  accuracy  problems.  The  problems  range  from 
data  field  omissions,  to  complete  unit  omissions  to  data  errors  and 
data  untimeliness.  The  data  inaccuracies  are  primarily  caused  by  the 
lack  of  complete  data  edits  and  audits,  lack  of  effective  systems 
configuration  control,  and  lack  of  a SACS  feedback/ corrective  mech- 
anism. 


The  study  team  concluded  that  SACS  data  are  neither  timely  nor 
accurate  for  all  M Force  units  selected  to  be  in  the  SACS  products. 

Recommendations  are  that  stringent  edits  be  established  for  data 
that  flows  to  SACS;  that  an  effective  audit  concept  be  implemented; 
that  a SACS  configuration  control  concept  be  implemented;  and  that 
a feedback/ correction  concept  be  implemented. 
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SECTION  1 
INTRODUCTION 

1.1  BACKGROUND 

This  report  covers  Task  C,  "Analyze  the  Accuracy  and  Timeliness  of 
Available  Data  Used  in  the  Current  LOGSACS  and  PERSACS,"  of  an  ODCSOPS 
project  entitled  "Analysis  to  Determine  Functional  and  Systems  Require- 
ments for  an  On-Line  Structure  and  Composition  System  (SACS) ,"  Contract 
Number  MDA  903-78-C-0445 , 26  September  1978.  Task  C required  that  c>i«“. 
data  flow  in  current  LOGSACS  and  PERSACS  products  be  analyzed  to  deter- 
mine if  they  met  the  timeliness  and  accuracy  requirements  necessary  to 
support  materiel  acquisitions  and  distributions;  and  personnel  recruit- 
ing, training,  reclassification,  promotion,  and  distribution  functions 
of  the  system.  The  task  objectives  were  to: 

• Determine  timeliness  of  data  flow 

• Determine  data  inaccuracies,  inconsistencies, 
incompatibilities,  and  inadequacies 


0 
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1.2  RESEARCH  METHODOLOGY 

Research  methodology  utilized  during  this  task  consisted  of: 

• Interviewing  functional  and  systems  personnel 

• Visiting: 

- US  Army  Research,  Development,  and  Acquisition 
Information  Systems  Agency  (RDAISA)  at  Radford, 
Virginia 

- US  Army  Depot  Systems  Command  (DESCOM)  at 
Chambersburg,  Pennsylvania 

- US  Army  Logistics  Evaluation  Agency  (LEA)  at 
New  Cumberland,  Pennsylvania 

- US  Army  Military  Personnel  Center  (MILPERCEN)  at 
Alexandria,  Virginia 
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• Evaluating  documentation  gathered  during  the  performance 
of  Task 

• Defining  and  analyzing  the  data  flow  from  origin  of  SACS 
data  to  SACS  customers'  use  of  such  data 

• Evaluating  and  analyzing  the  LOGSACS  and  PERSACS  data 
relative  to  the  system  objectives  as  documented  in 
Section  2,  this  report 

• Examining  interactions  between  associated  systems  and 
SACS  processing 

• Evaluating  the  validation  and  correction  feedback  mech- 
anism used  by  SACS 

1.3  SCOPE 

The  scope  of  this  task  encompassed  the  LOGSACS  and  PERSACS  products; 
their  use  by  the  three  principal  Army  Staff  agencies — the  Deputy  Chief 
of  Staff  for  Personnel  (DCSPER) , the  Deputy  Chief  of  Staff  for  Research, 
Development,  and  Acquisition  (DCSRDA) , and  the  Deputy  Chief  of  Staff  for 
Logistics  ( DCS LOG) ; and  users’  perceptions  of  SACS  data  and  problems 
encountered  in  applying  SACS  data  in  the  various  functional  systems  and 
processes.  Analyses  were  made  in  the  context  of  future  as  well  as  current 
SACS  requirements  and,  coupled  with  materials  and  insights  developed  dur- 
ing Task  B,'*'  will  serve  to  support  subsequent  tasks  leading  to  the  develop- 
ment of  an  improved  SACS. 


Analysis  to  Determine  Functional  and  Systems  Requirements  for  an  On- 
Line  Structure  and  Composition  System  (SACS) , Report  of  Task  B, 
Systems  and  Procedures  Documentation,  General  Research  Corporation, 
Report  Number  1070-01-79-CR,  15  January  1979. 
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SECTION  2 


SYSTEM  OBJECTIVES 


2.1  SACS  PURPOSE 

The  purpose  of  SACS  as  documented  in  Chief  of  Staff  Regulation  (CSR) 
18-11,  Force  Development  Management  Information  System,  18  February  1976, 
is  "to  provide  a capability  of  computing  force  structure  equipment  and/or 
personnel  requirements  and  authorizations  for  a real  or  hypothetical 
force,  for  the  current  year  and  each  of  a series  of  future  years."  CSR 
18-11  goes  on  to  say  that  "The  Force  Development  Management  Information 
System  (FDMIS),  part  of  the  Army  Management  Information  System  (AMIS), 
comprises  ODCSOPS  subsystems  containing  force  and  authorization  data 
which  can  be  selectively  manipulated  and  displayed  to  facilitate  manage- 
ment decisions.  The  major  subsystems  of  the  FDMIS  are:  Force  Accounting 
System  (FAS),  The  Army  Authorization  Documents  System  (TAADS),^  Table  of 
Organization  and  Equipment  (TOE)  Computational  System,  Structure  and 
Composition  System  (SACS),  and  Basis  of  Issue  Plan  (BOIP)  System."  Para- 
graph 5b  of  the  CSR  further  states  that  "Other  Army  Staff  Agencies  will: 

...  (3)  use  FDMIS  data  as  the  single  source  of  force  structure  data  in 
support  of  resource  management  requirements."  Accordingly,  ODCSOPS  has 
the  fundamental  responsibilities  for  providing  the  Army  Staff  (ARSTAF) 
and  field  activities  with  timely  and  accurate  requirements  and  authoriza- 
tions data  for  both  personnel  and  equipment  resource  management  and 
decision  making. 

2.2  SACS  OBJECTIVES 

The  objectives  stated  herein  represent  the  understanding  of  Army 
personnel  interviewed  by  the  GRC  project  team.  These  undocumented  objec- 
tives have  evolved  over  time  and  have  become  the  implied  current  objectives. 
These  should  be  recognized  as  a significant  expansion  of  the  original 

^ At  HQDA,  TAADS  data  are  being  handled  by  the  Authorizations  Subsystem 
(AS)  of  the  Force  Development  Integrated  Management  System  (FORDIMS) 
and  FAS  will  soon  be  replaced  by  the  Force  Structure  Subsystem  (FSS) 
of  FORDIMS. 
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CSR  18-11  statement  of  purpose.  The  evolved  objectives  which  are 
not  specifically  stated  in  Army  directives  are  to: 

• Provide  timzly  and  accuratz  cuMznt-yzar  resource 
requirements  and  authorizations  data  by  unit  identi- 
fication code  (UIC)  to  ARSTAF  and  field  activities 

to  zn*arz  that  pxopzrly  trainzd  pzuonnzl  and  co  meetly 
authorized  equipment  are  provided  to  unit!,  ba*zd  upon 
ichzdulzd  farce  * tructurz  changes. 

0 Provide  timely  and  accurate  budget:  and  program  yea*. 
resource  requirements  and  anticipated  authorizations 
data  by  UIC  to  ARSTAF  and  field  activities  to  zn*urz 
that  procurement,  recruitment,  training,  distribution, 
and  other  action*  involving  personnel  and  equipment 
are  properly  budgeted  by  major  commands  (MACOM)  , program 
directors,  and  appropriation  directors. 

• Provide  timely  and  accurate  out- year  resource  require- 
ments and  anticipated  authorizations  data  by  UIC  to 
ARSTAF  and  field  activities  to  ensure  that  procurement, 
recruiting,  training,  distribution,  and  other  actions 
are  planned  and  programmed,  and  that  authorization*  o£ 
both  personnel  and  zquljxnznt  can  bz  phased  far  allocation 
to  unit*  on  an  approved,  coordinated  *chzdulz. 

0 Provide  timely  and  accurate  current,  budgeted,  and  pro- 
grammed resource  requirements,  authorizations  or  antici- 
pated authorizations  data  to  thz  Oft  face  0$  thz  Secretar y 
o$  Defense  (OSD)  ion  joint  farce  planning  and,  through 
OSD,  to  thz  Congee**,  NATO,  and  other  *zrvice*. 

2.2.1  SACS  Timeliness  Objectives 

SACS  timeliness  objectives  may  be  described  as: 

a.  Producing  SACS  products  according  to  an  approved  scheduler 

^"Approved  schedule  as  prescribed  in  Chief  of  Staff  Memorandum  77-5-41, 
26  August  1977,  for  implementing  the  Management  of  Change  (MOC) 

3tudy . 
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• Twenty  work  days  for  PERSACS 

• Forty-five  work  days  for  LOGSACS 

b.  Producing  SACS  products  in  time  to  influence  decision-making 
processes. 

2.2.2  SACS  Accuracy  Objectives 

SACS  accuracy  objectives  are  to  provide: 

a.  Error-free  data  element  values  that  singularly  represent  a 
condition  or  event  and  collectively  represent  compatibility  between 
data  elements  and  records  at  a specified  "as  of"  date. 

b.  Complete  unit,  personnel,  and  equipment  data  for  a specific 
"as  of"  date  that  are  100%  accurate  in  representing  the  Master  Force  as 
selected  by  the  SACS  criteria. 

2.2.3  Interdependency  of  Timeliness  and  Accuracy 

A dependency  relationship  exists  between  timeliness  and  accuracy 
in  that  data  at  the  time  of  system  input  should  ideally  remain  valid 
6 to  9 months  later  when  that  data  is  used.  Therefore,  a SACS  objec- 
tive is  to  produce  data  that  is  as  accurate  at  the  time  it  is  used 
as  it  was  at  the  time  of  input  to  the  system. 


SECTION  3 


DATA  FLOW  AND  ANALYSIS 


3.1  SACS  DATA  FLOW 

Figure  3.1  is  a macro  flow  chart  showing  the  flow  of  SACS  data. 
SACS  fills  a central  or  integrating  role  among  the  ODCSOPS  systems.  It 
serves  to  synthesize  available  force  structure  data  and  provide  a coher- 
ent statement  of  Army  requirements  and  authorizations  for  functional 
users  in  DCSRDA,  DCSLOG,  DCSPER,  and  field  activities.  Through  these 
ARSTAF  agencies  and  their  field  activities  and  associated  MIS,  SACS  data 
flow  throughout  the  Defense  establishment  and  touch  most  personnel  and 
equipment-related  functions  and  activities  in  some  manner.  SACS  is 
clearly  critical  to  the  Army's  Planning,  Programming,  and  Budgeting 
processes  and  to  the  support  of  its  combat  mission. 


3.2  DATA  IDENTIFICATION 

The  data  identified  for  analysis  was  the  data  processed  by  five 
systems  supporting  SACS  (FAS,  TAADS,  TOE,  BOIP  and  SHN)  and  presented  in 
the  resultant  LOGSACS  and  PERSACS  products.  The  total  macro  flow  of  data 
was  examined  from  initial  guidance  formulation  to  the  distribution  of 
personnel  and  equipment.  Controlling  data  within  this  flow  is  derived 
from  the  FAS  and  TAADS. 


3.3  INPUT  DATA  AUTOMATION 

Input  to  the  SACS  process  is  completely  automated;  however,  the 
degree  of  automation  (i.e.,  extent  of  manual  intervention)  required  to 
develop  each  input  and  the  effectiveness  of  these  automated  processes 
vary  considerably.  The  lack  of  effective  automation  for  some  processes 
contributes  to  timeliness  and  accuracy  problems.  The  specific  automated 
processes  that  are  prime  candidates  for  upgrading  are  the  BOIP  and  SHN. 
These  processes  currently  require  approximately  2 to  3 weeks  to  complete 
because  of  their  manual  and  batch  processing  requirements.  Contributing 
to  these  problems  are  non-currency  of  supporting  data  bases  and  the  con- 
siderable amount  of  processing  time  required  to  produce  SACS  products. 
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Figure  3.1  Macro  Flow  Chart  - 


Discrepancies  between  FAS  and  TAADS  as  identified  in  the  SIGMA  process 
currently  require  an  inordinate  amount  of  time  to  correct.^-  For  internal 
SACS  processing,  the  most  time-consuming  processes  are: 


PERSACS  LOGSACS 

(20  days)  (45  days) 

SIGMA  10  days  6 days 

Batch  Type  Software  4 days  8 days 

BOIP  Batch  Type  Software  i , , , 

14  days 

SHN  Batch  Type  Software  I 

Manual  Review  Requirements  6 days  17  days 


The  state  of  the  current  automation  of  SACS  and  its  associated 
data  feeder  systems  contributes  to  many  data  inaccuracies.  Specific 
examples  are: 

• Ommission  of  units  from  both  LOGSACS  and  PERSACS. 

• Absence  of  split  unit  identification  in  PERSACS  and  LOGSACS 
and  the  lack  of  specific  identification  in  TAADS. 

• Lack  of  data  element  value  and  syntax  edits  in  current  SACS 
feeder  systems  and  in  SACS. 

• Untimely  or  lack  of  submission  of  TAADS  data  to  HQDA. 

• Blank  and  inaccurate  data  in  PERSACS  and  LOGSACS. 

These  inaccuracies  occur,  in  part,  because  the  feeder  systems  were  not 
designed  to  fulfill  SACS  needs  for  providing  resource  requirements  and 
authorizations  data  throughout  the  Defense  establishment.  Also,  because 
of  increased  emphasis  on  the  management  of  scares  Army  resources  in 
recent  years,  increased  use  of  and  emphasis  on  SACS  data  have  been 
necessary.  This,  in  turn,  has  lead  to  the  identification  of  timeliness 
and  accuracy  problems  which  existed  since  the  implementation  of  SACS  but 


^The  current  USAMSSA/ODCSOPS  FORDIMS  may  cause  this  situation  to  improve 
since  file  control  will  be  under  a data  base  management  system  (TOTAL) . 
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were  previously  of  little  consequence  since  the  data  were  not  used  as 
extensively.^  SACS  data  are  currently  used  in  most  aspects  of  personnel 
and  logistics  management  and  data  inaccuracies  are  being  found  with  each 
new  application  of  SACS  data. 

General  data  timeliness  and  accuracy  problems  (real  or  perceived) 
can  be  related  to  one  or  more  of  the  following  areas: 

• Evolutionary  transition  to  more  pervasive  use  of  LOGSACS  and 
PERSACS  data 

• Insufficient  data  edits 

• Lack  of  data  audits 

• Faulty  feedback  and  corrective  mechanisms 

• Absence  of  BOIP  and  SHN  in  PERSACS 

• Inadequate  data  management 

• Undefined  source  of  requirements  and  authorizations  data 
Each  of  these  areas  will  be  discussed  in  detail  in  material  which  follows. 


3.4  TIMELINESS 

SACS  outputs  generally  are  produced  according  to  schedules  pre- 
scribed by  the  ARSTAF,  although  there  have  been  instances  where  input 
or  processing  delays  and/or  rerun  requirements  have  caused  both  the  LOG- 
SACS  and  PERSACS  to  be  delivered  well  after  the  scheduled  due  dates. 

More  importantly,  the  principal  recipients  and  users  of  the  SACS  data 
including  MILPERCEN,  DESCOM,  and  RDAISA,  have  indicated  that  data  con- 
tained in  SACS  products  are  frequently  outdated  even  though  the  SACS 
products  were  delivered  on  schedule. 


The  implementation  of  the  management  of  change  (MOC)  study  has  caused 
the  TAADS  data  flow  from  MACOMS  to  HQDA  to  be  reduced  to  two  semi-annual 
90-day  periods  each  year. 
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3.4.1  Data  Availability  Relationships 


Figure  3.2,  Data  Availability  Relationships,  graphically  represents 
the  timing  of  data  availability  time  for  SACS  processing.  The  top  line 
portrays  a representative  19-month  time  span,  including  two  MOC  windows. 

The  three  horizontal  boxes  represent  the  data  bases  of  the  FAS,  TAADS 
and  TOE,  respectively,  with  scheduled  updates  indicated.  On  the  two 
levels  beneath  the  quarterly  production  of  PERSACS  and  LOGSACS  products 
are  shown.  The  bottom  level  depicts  the  recurring  and  ad  hoc  TAADS  reports 
(shown  as  "TAADS  Retrieval  Data  Base"  also  erroneously  called  the  "Mini 
SACS"),  some  of  which  are  produced  on  either  the  10th,  20th,  or  30th  of 
each  month  of  the  year.  The  slanted  and  vertical  lines  represent  the 
origin  and  "as  of"  date  of  FAS,  TAADS,  and  TOE  data  when  extracted  for 
SACS  purposes.  For  example: 

• The  SACS  runs  for  quarters  ending  March  and  September  use 
TAADS  data  that  were  held  for  as  much  as  90  days;  FAS  data 
that  are  updated  daily;  and  TOE  data  that  are  updated  monthly. 
SACS  runs  during  these  quarters  produce  products  based  on 
guidance  that  is  as  much  as  157  days  old  in  terms  of  data 
contents. 

• The  SACS  runs  for  quarters  ending  June  and  December  use  TAADS 
data  that  were  held  as  much  as  180  days;  FAS  data  that  are 
updated  daily;  and  TOE  data  that  are  updated  monthly.  SACS 
runs  produce  products  based  on  guidance  that  is  as  much  as 
247  days  old  in  terms  of  data  contents. 

The  SACS  data  from  the  end  of  March  and  September  are  more  timely  and 
hence  more  accurate  than  the  SACS  data  from  the  end  of  June  and  December. 
This  difference  shows  clearly  in  TAADS  data  comparisons  made  in  conjunction 
with  personnel  and  equipment  requisision  validation  processes. 


L 

C 

0 

D 


As  a further  illustration,  reports  produced  as  of  the  30  of  January, 
as  derived  from  the  TAADS  Retrieval  Data  Base,  receive  data  from  the  FAS 
Data  Base  which  was  updated  the  same  day.  These  data  are  less  than  24 
hours  "old."  The  SACS  reports  as  the  30th  of  January  also  derive  data 
from  the  TAADS  data  base;  however,  the  last  time  that  data  were  completely 
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updated  was  on  the  30th  of  September  of  the  previous  year,  or  4 months 
previously. 

Timeliness  of  data  is  even  more  critical  in  a situation  such  as 
the  following.  On  the  15th  of  February  1979,  a supply  distribution 
manager  uses  the  31  December  LOGSACS  to  validate  a current  requisition 
for  a major  item  of  equipment.  The  validation  decision  in  some  instances 
cannot  be  made  at  the  MRC  and  referral  to  EARA  is  necessary.  Changes  to 
TAADS  authorizations  provided  to  the  unit  by  MACOM  may  still  not  reflect 
in  SACS  as  much  as  9 months  later. 

3.4.2  SACS  Data  Flow  Network 

Figure  3.3,  SACS  Data  Flow  Network,  shows  the  systems  that  provide 
data  to  SACS.  Page  1 depicts  the  interdependent  activities  which  are 
required  to  introduce  new  data  and  update  or  change  existing  data  in 
each  of  the  five  supporting  SACS  systems  (TAADS-event  11,  FAS-event  13, 
TOE-event  19,  BOIP-event  26,  and  SHN-event  20).  The  heavy  activity  lines 
and  heavy  event  circles  depict  the  direct  SACS  flow  of  data. 

Page  2 of  Figure  3.3,  depicts  the  distribution  of  PERSACS  and  LOG- 
SACS  data  tapes  and  the  general  flow  o:  resource  requirements  and  authori- 
zations data  to  the  personnel  and  logistical  functions  of  the  Army.  This 
also  indicates  the  important  and  critical  position  of  SACS  in  administering 
these  two  functions  and  how  the  SACS  data  are  intertwined  in  the  sub- 
functions of  personnel  and  logistics  management.  This  illustrates  the 
pervasive  nature  of  SACS  data,  since  SACS  is  an  important  aid  in  formu- 
lating and  changing  the  Army's  annual  Five  Year  Defense  Program  (FYDP) 
and  budget,  as  well  as  in  executing  the  approved  program  and  budget  in 
the  current  year  (the  actual  distribution  of  approved  resources). 

Figure  3.3  relates  to  Figure  3.1.  Figure  3.1  identifies  resource 
requirements  and  authorizations  data  flow  between  organizations  or  systems, 
or  both,  from  generation  of  initial  guidance  through  the  various  systems 
to  PERSACS  and  LOGSACS,  and  on  to  the  actual  recipients  of  these  SACS 
products.  Figure  3.3,  on  the  other  hand,  identifies  the  general  activity 


(30) 


(90) 


(30) 


(5) 


(20) 


Subcmds  and  Instls 
input  MACOM  MTOE 
data  into  ITAAOS  and 
formulates  and  inputs  T OA 


tTAF  evaluates  and 
Amits  last  minute 
quipment  changes 
I SACS  equipment 
Analyst 


SACS  Equipment 
Analyst  develops 
note  and  submits 
tc  USAMSSA 


USAMSSA  applies 
shorthand  note 
to  file 


Data  Flow  Network 


19 


It) 


USAMSSA  Creates 
7 A AOS  Retrieval 
Data  on  10th 
20th.  30th 
Ol  each  month 


(IS) 


USAMSSA  produces 
PERSACS  tapes 
and  reports 


(45) 


USAMSSA  produces 
LOGSACS  Tapes 
end  Reports 


USAMSSA  forwards  POM  LOGSACS 
to  Army  Research  and  Development  Acquisition 
Information  Systems  Apency  (RDAISA) 


Figure  3.3  SACS  Data  Flow  Non 


Numerous  reports  submitted  to  ^ 


various  A RSTAF  and 
Field  Activities 


Repons  used  for 
personnel  and 
logistic  management 
decisions  and 
compared  with 
Quarterly  SACS  Reports 


Numerous  reports  submitted  to 
S MILPERCEN 


Reports  used  lor 
actiom  by  MILPERCEN 


112  II  Months) 
RECRUITING  ol  Army 
personnel  based  on  PERSACS  . 


MILPERCEN  processes  PERSACS  Tapes 
to  produce  numerous  quarterly  reports 
I*  be  used  by  personnel  manager! 


/ (311  Months) 
y'  TRAINING  ol  Army 

personnel  based  on 

PERSACS^ " 


(2-6  Months) 
ASSIGNMENTS  ol 
Army  personnel 
— abated  on  PERSACS 


/// 
£// 
4>  *?/ 


(6  18  Months) 
v PROMOTIONS  ol  Army 
\ personnel  based  on 
\.  PERSACS 


?l°C. 


i I®  -serlt 
idsl"*'” 


(60)  ^ 

OM  forwards  equipment 
distribution  information 
to  LEA 


(90)  (301 

LEA  forwards  total  Logistic  OCSLOG  determines 

^Readiness  Sustainability  Reports  distribution  priorities  and  police 
to  OCSLOG  Z***' 


gtscoe  !«■**  ,,"11‘^SJ”*!WI 

nirtributioh  Prot^L 


DESCOM  forwards  Total  Arm,  Equipment 
_ Distribution  Program  (TAEOP)  to  MACOM 


OESCOM 


AMMUNITION 


lordsoqo^NT 


56  J MACOM  reports  equipment 
^^eAvstetus information  to MRC 


0fSC0*"«n^ 

**•**'>  ~Z?HS30'*<  of 


11W 

ROAISA computes Initial  ^ “^J^J^^MRC 
Army  Requisition  Obtectwe  (AAO)  end  fonw^ . 


3.3  SACS  Data  Flow  Network  (con’t) 


fuel 


it  to  Unin . 


m 

e«lo  DESCOM 


MRC  manages 
War  Rammos 


that  takes  place  between  events  and  the  approximate  number  of  days 
required  to  complete  the  general  activity. 


r”"  ~ 


I 

I 


I 


I 


[ 

- 


D 


n 


0 


0 

:: 


:: 

c 

o 


3.4.3  PERSACS  Timeliness 

The  schedule  for  producing  PERSACS  is  not  a major  problem.  How- 
ever, as  previously  illustrated,  PERSACS  data  are  untimely  for  the  vali- 
dation of  personnel  requisitions  in  the  current  MILPERCEN  requisition 
validation  (REQVAL)  process,  and  especially  in  the  Personnel  Deployment 
and  Distribution  Management  System  (PERDDIMS) . PERDDIMS  is  being  designed 
to  replace  field-submitted  requisitions  with  top-of-the  system  (MILPERCEN) 
generated  requisitions.  PERDDIMS  field  tests  evaluated  PERSACS  data  and 
concluded  that,  "...present  PERSACS  precludes  the  distribution  of  soldiers 
in  a timely  and  accurate  manner..."'*'  This  conclusion  was  based  on  com- 
parison of  PERSACS  data  to  the  unit  authorization  documents  used  for 
developing  personnel  requisitions.  Installations  and/or  MACOMS  involved 
and  results  were  as  follows: 

• Ten  Fort  Belvoir  units  representing  TRADOC,  FOKSCOM,  Corps 
of  Engineers,  DARCOM,  Health  Services,  Army  Communications 
Command,  and  a Joint  Activity  were  tested  with  compatibility 
results  ranging  from  40%  to  100%.  Three  units  had  100% 
compatibility,  two  units  92%  compatibility,  and  the  remaining 
five  units  had  compatibility  scores  of  87%,  82%,  77%,  58%, 
and  40%. 

• Twenty-two  units  of  the  U.S.  Army  Communications  Command 
(ACC)  were  tested  with  results  ranging  from  37.7%  to  100%. 

These  22  ACC  units  were  located  in  CONUS  and  overseas;  at 
FORSCOM,  Health  Services,  and  DARCOM  installations  and  in 

^PERDDIMS  Task  Force,  Memorandum  for  the  Record,  13  February  1979,  Subject: 
"Results  of  the  PERDDIMS  Functional  Field  Test  (FFT) — Information  Memorandum." 

2 

The  PERSACS  data  used  for  this  test  was  the  quarter-end  September  1978 
PERSACS,  a product  of  the  MOC  open  window.  This  condition  should  present 
the  most  timely  data  since  the  quarter-end  December  1978  PERSACS  utilizes 
identical  TAADS  data  which  is  then  90  days  older. 


TV- 


Germany,  Italy,  and  Turkey.  Six  of  these  ACC  units  involved 
"split"  segments  at  different  geographical  locations. 

October  1978  compatibility  ranged  from  70%  to  100% 

April  1979  compatibility  ranged  from  37.7%  to  100% 

The  primary  cause  for  the  lower  compatibility  was  the  requi- 
sitioner's  use  of  newer  authorizations  than  those  reflected 
in  PERSACS. 

• Ten  Fort  Riley  units  representing  FORSCOM,  TRADOC,  Health 
Services,  and  Army  Communications  Command  were  tested  with 
compatibility  results  ranging  from  84.1%  to  99.4%.  Three 
units  had  less  than  90%  compatibility  with  one  TRADOC  split 
unit  (WIJEAA)  having  personnel  stationed  at  63  different 
geographical  locations  spread  over  12  mid-western  states. 

One  FORSCOM  unit  (WDZNAA)  had  a company  located  at  Fort  Polk — 
another  split  unit.  In  both  instances,  PERDDIMS  would  assign 
replacement  personnel  to  the  parent  unit  location  rather  than 
the  true  location  that  had  the  requirement  and  authorization. 

• Twenty-three  USAREUR  units,  located  in  Germany,  Berlin, 

Italy,  and  Turkey,  were  tested  with  compatibility  ranging 
from  75.4%  to  100%.  Compatibility  statistics  for  December 
1978  were  18  units — 100%;  5 units  ranged  from  97.1%  to  98.6%. 
The  same  units'  compatibility  statistics  for  September  1979 
were:  13  units — 100%;  10  units — ranged  from  75.4%  to  98.6%. 

A principal  cause  for  compatibility  was  the  use  of  newer 
authorization  documents  by  the  requisitioner . 

Some  additional  specific  problems  and  unit  identification,  statistics  and 
remarks  are  provided  in  Appendix  I. 

3.4.4  LOGSACS  Timeliness 

The  LOGSACS  production  schedule  is  a timeliness  issue,  especially 
the  first  LOGSACS  produced  after  the  turn  of  each  fiscal  year,  which  is 
for  the  POM.  It  is  important  that  this  LOGSACS  contain  the  latest  data 
available;  hence,  it  must  contain  the  TAADS  data  input  to  HQDA  during 
the  July-September  MOC  window.  The  October  1978  LOGSACS  was  not  received 
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at  RDAISA  until  15  December.  RDAISA  has  the  responsibility  for  computing 
the  IIQ/AAO  for  all  items  of  equipment  and  providing  them  to  the  Material 
Readiness  Command  (MRC)  by  early  January  (Activity  57-58,  Figure  3.3). 

The  MRC  must  complete  their  actions  and  submit  data  through  DARCOM  to 
DCSRDA  for  the  May-June  POM  submission  (Activity  54-58,  Figure  3.3). 

The  current  LOGSACS  production  schedule  does  not  allow  RDAISA  sufficient 
time  for  reviewing,  analyzing,  and  correcting  LOGSACS  data  prior  to  their 
use  in  the  important  computations  of  IIQ/AAO.  Therefore,  any  delays  in 
providing  LOGSACS  or  requirements  to  research  and  correct  its  data,  cause 
all  personnel  involved  in  preparing  the  procurement  program  to  feel  the 
time  squeeze. 

Each  quarterly  LOGSACS  is  important  to  DESCOM  since  it  is  the  basis 
for  preparing  the  Total  Army  Equipment  Distribution  Program  (TAEDP) 
(Activity  54-55  and  54-56,  Figure  3.3)  and  the  Phased  Equipment  Moderni- 
zation (PEM)  System  as  well  as  the  H-530  report.  The  H-530  report  is 
forwarded  to  each  MRC  (Activity  54-58,  Figure  3.3):  it  reflects  equip- 
ment authorizations  by  UIC  and  it  is  the  document  used  for  validating  unit 
equipment  requisitions.  In  each  instance  when  MRC  cannot  validate  a 
requisition  telephonically , the  U.S.  Army  Equipment  Authorizations  Review 


Agency  (EARA)  is 
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the  majority  of  the  "H-530  not  current"  problem  requisitions  are  trace- 
able to  instances  where  units  have  newer  documents  in  their  possession 
than  were  available  in  LOGSACS  to  prepare  the  H-530  report. 
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3.4.5  SACS  Production  Schedule  Components 

The  SACS  production  schedule  components  that  consume  time  are 
identified  in  paragraph  3.3  above.  Each  SACS  component  consumes  time 
related  to  a condition  as  follows: 

SACS  Component  Condition 

SIGMA  This  SACS  preprocessor  is  utilized  to  match  FAS  and 

TAADS  data  and  correct  obvious  error  conditions. 

This  is  essential  because  no  continuous  interface 
processing  exists  between  FAS  and  TAADS.  Frequently, 
multiple  SIGMA  runs  are  essential  to  correct  data 
in  the  FAS  prior  to  each  basic  SACS  run  to  ensure 
a maximum  match  of  TAADS  and  FAS  records.  SIGMA 
processing  can  require  at  least  one  week  and  fre- 
quently more  to  correct-  the  errors  identified  when 
matching  FAS  and  TAADS. 

Batch  Processing  The  entire  SACS  processing  is  sequential  batch  via 

magnetic  tape.  The  software  system  is  second 
generation  processing  although  run  on  fourth 
generation  computer  hardware.  This  type  processing 
requires  an  inordinate  amount  of  clock  computer 
time  in  comparison  to  actual  central  processing  unit 
(CPU)  time  because  of  sequential  tape  handling. 
Through  each  program  of  the  system, tape  handling  is 
required  to  include  mounting  and  dismounting  on 
tape  drives.  The  library  handling  and  cataloging 
functions  of  the  magnetic  tapes  also  require  much 
time.  Errors  are  easily  introduced  through  manual 
tape  processing  and  handling.  The  BOIP  and  SHN 
applications  are  also  sequential  batch  processing. 

The  computer  processing  consumes  appropriately  4 
days  for  PERSACS  and  approximately  8 days  for 
LOGSACS.  The  principal  difference  is  the  applica- 
tion of  BOIP  and  SKri  in  LOGSACS. 

Manual  Review  The  manual  review  process  is  almost  exclusively 

devoted  to  checking,  verifying,  and  auditing 
initial,  intermediate  or  final  output  reports  be- 
fore the  SACS  products  are  released  to  SACS  data 
users.  This  manual  effort  is  accomplished  in  DCSOPS 
(DAMD-FDA) . The  effort  consumes  up  to  1 week  for 
PERSACS  and  between  2 and  3 weeks  for  LOGSACS.  This 
review  process  is  assisted  by  automated  programs,  the 
Personnel  Authorizations  Analysis  System  (PAAS)  for 
PERSACS  and  Basis  of  Issue  Monitoring  and  Recording 
System  (BOIMARS)  for  LOGSACS.  These  programs  do  not 
perform  complete  audits  of  data  contents. 
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3 . 5 DATA  ACCURACY 

SACS  products  generally  involve  considerable  inaccurate  or  missing 
data  in  each  run.  As  a result,  user  confidence  in  SACS  output  is  such 
that  they  frequently  question  perfectly  valid  information.  There  are 
many  reasons  for  inaccurate  data  in  SACS  ranging  from  errors  committed 
at  time  of  input  into  a feeder  system  to  SACS  processing.  Significant 
reasons  for  SACS  data  inaccuracies  have  been  previously  categorized 
under  general  areas  identified  in  paragraph  3.3,  and  are  explained 
further  in  the  following  paragraphs  and  in  the  appendixes. 

3.5.1  The  Nature  of  LOGSACS  and  PERSACS  Data 

SACS  has  evolved  over  the  past  decade  from  a system  that  was 
intended  to  provide  requirements  and  authorizations  data  for  validating 
requisitions  to  a system  that  attempts  to  provide  much  broader  informa- 
tion. These  data  are  now  used  for  various  functional  requirements  such  as: 
recruiting  objectives;  training  requirements;  promotion  objectives;  and 
equipment  distribution,  initial  issue  quantity.  Army  acquisition  objectives, 
and  phased  equipment  modernization  actions. 

SACS  data  are  currently  used  so  extensively  throughout  the  Army, 
that  SACS  is  becoming  the  Army's  mat.  important  management  information 
system.  In  Appendix  B,  the  evolutionary  transition^to  more  pervasive  use 
of  LOGSACS  and  PERSACS  is  discussed. 

3.5.2  Data  Edits 

A very  important  aspect  of  systems  development  is  specifying  ade- 
quate edits  of  individual  and  related  data  values.  SACS  as  a system  main- 
tains no  data  base.  Therefore,  when  SACS  obtains  data  from  FAS,  TAADS , 

TOE,  BOIP,  and  SHN,  it  must  be  complete,  timely,  accurate,  and  interface 
effectively.  Otherwise  SACS  products  contain  inaccurate  data.  Either 
inadequate  or  no  edits  exist  in  the  aforementioned  systems.  Therefore, 
inaccurate  data  or  blank  data  element  fields  are  passed  to  SACS  and  on  to 
users  of  LOGSACS  and  PERSACS.  (For  example,  RDAISA,  DESCOM,  and  MILPERCAN 
have  cited  specific  invalid  or  blank  data  fields.)  In  Appendix  C,  data 
edits  are  discussed  and  general  examples  are  cited.  In  Appendix  I specific 
examples  are  identified. 
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3.5.3  Data  Audits 

Current  SACS  processing  utilizes  no  technique  of  quality  assurance 
to  confirm  the  presence  of  all  FAS  units  that  meet  the  SACS  force 
selection  criteria  in  the  LOGSACS  and  PERSACS.  Also,  there  is  no  current 
method  employed  to  assure  that  all  units  have  equipment  and  personnel 
detail  data,  as  appropriate.  It  is  recognized  that  an  effective  data 
audit  for  all  data  elements  in  SACS  would  be  impractical;  however, 
accounting  for  all  records  and  assuring  their  completeness  is  a feasible 
alternative.  SACS  products  are  frequently  incomplete  when  released  to 
users  and  ODCSOPS  is  advised  of  omissions  only  when  users  begin  to  process 
the  LOGSACS  or  PERSACS.  In  the  October  1978  and  January  1979  SACS  runs, 
data  problems  were  reported  by  users  that  data  audits  could  have  detected. 

In  Appendix  D is  a more  detailed  discussion  of  data  audits;  in  Appendix  I 
are  examples  of  specific  data  ommissions  that  a data  audit  technique  could 
have  detected  and  for  which  corrective  action  could  have  been  taken  prior 
to  dispatching  the  PERSACS  and  LOGSACS  products. 

3.5.4  Feedback  and  Correction  Mechanism 

SACS  has  no  satisfactory  automated  and  directly  interfaced  mechanism 
to  correct  data  or  to  feed  data  problems  to  other  systems  so  that  they 
may  be  corrected.  The  SACS  Branch  currently  corrects  data  problems 
by  rerunning  SACS  or  obtaining  correct  data  and  relaying  it  by  telephone 
to  appropriate  agencies.  SHN  are  the  only  data  under  exclusive  DAMO-FDA 
control.  All  other  data  used  in  SACS  are  controlled  by  other  ARSTAF  or 
field  activities.  In  some  cases  one  data  element  is  "controlled"  by  more 
than  one  office.  Frequently,  what  appears  to  be  a simple  error  in  SACS 
data  becomes  a major  problem  to  correct.  A data  element  that  currently 
is  in  this  category  is  the  identity  code  (female,  male,  or  either).  When 
TAADS  detail  data  are  not  available,  SACS  must  use  TOE  detail  as  the 
source  for  personnel  data.  The  identity  code  is  not  maintained  in  TOE 
and  the  PERSACS  products  do  not  include  this  important  code  when  TOE  details 
are  included  in  PERSACS  products.  Other  data  elements  equally  difficult  to 
correct  are:  ADCON;  DAMPL/DAPPL;  Category;  POMCUS  ID;  and  others.  In 
Appendix  E is  a further  discussion  of  feedback/corrective  mechanism. 
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3.5.5  BO IP  and  SHN  in  PERSACS 

The  PERSACS  output  does  not  reflect  changes  in  personnel  require- 
ments based  on  equipment  modernization  programs  because  BOIP  data  are 
not  applied  to  PERSACS  output.  SHN  could  be  used  to  refine  or  to  add 
personnel  data  by  SRC  or  UIC.  In  some  cases,  the  current  practice  is 
to  drop  a unit  from  PERSACS  because  the  unit  personnel  detail  data  are 
missing.  By  using  SHN,  this  practice  would  not  be  necessary  and  PERSACS 
data  would  improve. 

The  BOIP  is  currently  being  used  in  MILPERCEN,  via  manual  methods 
to  modify  SACS  data  to  determine  recruiting  and  training  requirements. 
This  approach  is  labor  intensive,  subject  to  error,  and  never  computes 
the  total  BOIP  impact.  The  BOIP  and  SHN  must  be  built  into  PERSACS  pro- 
cesses in  a manner  similar  to  that  used  by  LOGSACS.  The  absence  of  BOIP 
and  SHN  in  PERSACS  is  discussed  in  Appendix  F. 

3.5.6  Data  Management 

Data  management,  to  be  effective,  must  consist  of  control  over  all 
aspects  of  systems  development  and  information  flow  from  systems.  The 
control  must  be  exercised  by  senior  personnel  to  ensure  broad  oversight 
over  all  systems  in  a functional  area.  For  example,  within  ODCSOPS, 
no  system  should  be  changed  without  first  advising  the  particular  ODCSOPS 
proponents  of  each  participating  system  of  the  impending  change.  Data 
management  must  consider  the  flow  of  information  from  point  of  data  cap- 
ture through  all  systems,  including  interface  systems,  to  the  ultimate 
data  users.  When  more  than  one  system  feeds  data  to  a synthesizing  system 
like  SACS,  data  management  should  be  under  the  control  of  an  agency  with 
day-to-day  operational  responsibility  for  system  changes  as  well  as  system 
operation.  For  example,  when  the  equipment  requirement  code  (ERC)  was 
implemented  in  TAADS,  simultaneous  action  was  not  taken  for  TOE  imple- 
mentation so  that  it  could  be  provided  to  SACS  from  either  TAADS  or  TOE. 
Currently,  when  MTOE  details  are  not  available  in  TAADS,  SACS  obtains  the 
required  detail  from  TOE  where  the  ERC  has  not  been  implemented. 
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Data  management  within  DAMO-FD  is  fragmented  among  three  divisions. 
The  maintenance  of  the  M Force  is  split  into  the  current  year  and  budget 
year,  with  responsibility  assigned  to  DAMO-FDP,  and  the  program  out  years, 
with  responsibility  assigned  to  DAMO-FDF.  To  further  complicate  this, 
the  input  responsibility  for  updating  the  M Force  for  all  years  is 
assigned  to  DAMO-FDA.  The  force  structure  data  management  takes  on  a 
more  complicated  aspect  since  the  TAADS  responsibility  resides  with  DAMO- 
FDU,  when  in  fact,  DAMO-FDU  has  an  automation  responsibility  with  no 
direct  responsibility  for  the  personnel  and  equipment  data.  TAADS  func- 
tional responsibilities  accrue  to  DCSPER  and  EARA  as  follows: 

• The  personnel  section  of  TAADS  documents  (Section  II)  is  a 
direct  DCSPER  responsibility.  The  guidance  for  the  details 
of  Section  II  is  issued  by  MILPERCEN  in  AR  611-101  and 

AR  611-201.  Since  this  guidance  must  be  implemented  in 
Section  II  of  TAADS  documents  it  seems  only  logical  that 
MILPERCEN  rather  than  DCSPER  should  have  Section  II  TAADS 
review  responsibility. 

• The  equipment  section  of  TAADS  documents  (Section  III)  is 
the  responsibility  of  DCSLOG  but  delegated  to  EARA.  EARA 
functions  for  DCSLOG  to  maintain  unit  equipment  authorizations 
data  and  is  able  to  confirm  for  DCSLOG  unit  authorizations  at 
any  point  in  time  based  on  all  Army  actions  taking  place. 

Appendix  G and  its  inclosure  contain  additional  information  con- 
cerning data  management.  The  inclosure  points  out  that  the  "SACS  Respon- 
sible Agency"  is  dependent  upon  the  "Feeder/Coordinating  Agency"  for  the 
quality  of  data  input  to  SACS.  Also,  since  SACS  (DAMO-FDA)  is  an  end- 
user  of  force  structure  data  in  preparing  the  PERSACS  and  LOGSACS,  that 
office  is  the  responsible  agency  for  coordinating  SACS  problems.  At 
the  current  time  DAMO-FDA  does  not  have  a mechanism  to  influence  what 
happens  in  DAMO-FDP,  DAMO-FDF,  DAMO-FDU,  and  DAPE-MBA. 


3.5.7  Source  of  Requirements  and  Authorizations  Data 

CSR  18-11  states  an  Army  policy  that  the  source  of  requirements  and 
authorizations  information  is  the  SACS.  This  information  is  provided  in 
the  form  of  PERSACS  and  LOGSACS . The  SACS  data  are  under  increased 
scrutiny  because  of  increased  uses  and  importance  attached  to  them. 

While  this  is  true,  it  is  also  true  that  much  reliance  is  still  placed 
on  TAADS  data  at  the  HQDA,  MACOM,  installations,  units,  and  HQDA  field 
activities.  USAMSSA  operates  a TAADS  retrieval  data  base  and  provides 
reports  that  are  similar  to  SACS  reports,  but  the  TAADS  data  are  incom- 
plete when  compared  to  SACS  data,  since  only  those  TAADS  documented 
units  that  match  FAS  on  UIC  and  EDATE  are  included  in  this  retrieval 
data  base. 

For  requisition  validation  purposes,  MILPERCEN  frequently  uses 
TAADS,  VTAADS,  or  installations  data  provided  by  telephone.  MILPERCEN 
also  maintains  SACS  requirements  and  authorizations  data  which  are  fre- 
quently altered  based  on  information  obtained  from  various  sources, 
other  than  SACS.  AR  310-49  specifies  that  TAADS  will  be  the  source  for 
authorizations  information.  In  reality  TAADS  is  only  a partial  source 
for  authorizations.  Since  TAADS  or  TOE  can  be  used  in  SACS  and  either 
TAACS  or  TOE  strengths  can  be  factored  to  match  the  strengths  in  the  FAS, 
TAADS  is  not  always  more  valid  than  SACS  information.  Appendix  H is  a 
further  discussion  of  sources  of  requirements  and  authorizations  data. 

3.5.8  Specific  Timeliness  and  Accuracy  Problems 

Appendix  I documents  26  specific  examples  of  timeliness  or  accuracy 
problems.  Other  specific  problems  are  identified  and  discussed  in  the 
body  of  this  report  ot  its  other  appendixes.  There  are  real  and  perceived 
problems  in  SACS  data. 

The  Army  personnel  contacted  with  respect  to  identifying  specific 
data  timeliness  and  accuracy  problems  related  to  PERSACS  and  LOGSACS 
were  employed  in  MILPERCEN,  DESCOM,  RDAISA,  and  EARA. 
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The  MILPERCEN  personnel  seem  to  utilize  the  PERSACS  data  in  their 
daily  processes  much  more  extensively  than  do  the  personnel  at  DESCOM, 
RDAISA,  or  EARA.  The  principal  reason  for  this  is  that  MILPERCEN  is 
responsible  for  the  total  personnel  asset  picture  from  recruiting  quotas, 
to  training,  redistribution,  promotion,  and  reassignment  and  reclassifi- 
cation, whereas,  the  logistic  functions  of  procurement,  distribution, 
and  redistribution  are  decentralized  in  six  MRC  and  functional  organiza- 
tions. The  MILPERCEN  centralization  concept  causes  the  PERSACS  data 
to  be  extensively  processed  and  handled  by  many  personnel  within  one 
organization.  On  the  other  hand,  the  decentralized  concept  under  which 
the  logisticians  currently  operate  causes  LOGSACS  to  be  processed  and 
handled  by  a few  personnel  at  each  aforementioned  organization.  From 
this  viewpoint,  the  LOGSACS  problems  of  timeliness  and  accuracy  are 
significant  and  relatively  easy  to  identify.  The  PERSACS  problems  of 
timeliness  and  accuracy  are  just  as  significant  but  not  as  easily  identi- 
fied because  of  the  extensive  internal  MILPERCEN  processing  of  the  PERSACS 
data.  In  this  respect,  though  MILPERCEN  has  real  problems  with  PERSACS, 
as  the  entries  on  Appendix  I indicate,  some  are  internal  MILPERCEN  prob- 
lems. One  MILPERCEN  officer  said,  "There  is  common  agreement  that  prob- 
lems exist  in  the  PERSACS  data  base;  but,  there  is  not  common  agreement 
as  to  the  loci  of  the  problems  nor  the  solutions.  A majority  of  the 
problems  are  recognizable  but  inexplicable. " ^ 

3.5.9  FORDIMS  Contributions  to  SACS  Improvements 

FORDIMS  will  make  minimal  contributions  to  the  improvement  of  data 
timeliness  and  accuracy  in  either  the  LOGSACS  or  PERSACS.  A most  signifi- 
cant improvement  will  be  implementing  the  gt udance.  tSia.du.ng  psioc&duAe.. 
Since  this  procedure  will  aid  in  the  exercise  of  greater  control  over 
authorizations  by  MACOM,  it  should,  over  time,  reduce  the  number  of  units 
that  have  spaces  factored. 


^DAPC-EPS-0  Disposition  Form,  Subject:  "Identification  of  PERSACS  Problem 
Areas,"  18  October  1978. 
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The  data  edits  implemented  in  FORDIMS  are  data  element  value  edits 
only.  Relationship  compatibility  type  edits  discussed  in  the  body  of 
this  report  and  Appendix  C are  not  being  implemented  in  either  the  Force 
Structure  Subsystem  (FSS)  or  the  Authorizations  Subsystem  (AS). 

Timeliness  of  force  structure  data  flow  to  SACS  and  on  through 
PERSACS  and  LOGSACS  to  users  in  MILPERCEN,  RDAISA,  and  DESCOM  will  not 
vary  since  the  data  flow  into  each  SACS  feeder  system  remains  unchanged 
under  FORDIMS. 

In  Appendix  J is  a more  detailed  discussion  of  the  impact  of 
FORDIMS  on  SACS. 
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SECTION  4 


CONCLUSIONS 


This  review  of  the  accuracy  and  timeliness  of  SACS  data  establishes 
that  SACS  data  is  neither  timely  nor  accurate  for  all  the  M Force  units 
selected  to  be  in  SACS  products.  Specific  conclusions  are  as  follows: 


1.  There  is  a general  lack  of  understanding  of  the  pervasiveness 
and  importance  of  SACS  within  the  total  operation  of  the  Army.  This  lack 
of  understanding  erodes  the  quality  of  data  and  the  cooperative  manage- 
ment of  all  supporting  systems. 


2.  LOGSACS  and  PERSACS  data  are  not  timely  because  the  data  ex- 
tracted from  SACS  supporting  data  bases  are  not  always  current.  Incom- 
patible timing  of  supporting  systems  from  which  SACS  selects  data  is 
partly  related  to  the  MOC  window  and  the  TAADS  data  flow  is  not  conducive 
to  producing  timely  SACS  data. 


3.  There  are  a lack  of  data  value  edits  and  data  compatibility 
edits  within  or  between  SACS  supporting  systems. 


4.  There  are  no  complete  audits  in  SACS  to  ensure  that  all  units 
and  records  are  included  in  LOGSACS  and  PERSACS  products.  Omissions  of 
detail  and,  more  important,  omissions  of  units  can  occur  and  pass  to 
the  PERSACS  and  LOGSACS  users  undetected. 


5.  There  are  no  feedback,  corrective  and/or  interfacing  mechan- 
isms for  resolving  erroneous  data  conditions  within  and  between  supporting 
svstems  of  SACS. 


6.  The  absence  of  BO IP  and  SHN  data  in  the  PERSACS  creates  a 
fundamental  disparity  between  data  in  the  LOGSACS  and  PERSACS  with 
respect  to  its  completeness  and  mutually  supportive  nature. 


7.  The  management  of  data  quality  both  within  the  automated  and 
the  manual  procedures  is  inadequate  in  that  it  allows  unacceptable  and 
unusable  data  to  pervade  SACS  products. 

8.  Multiple  sources  of  requirements  and  authorizations  data  con- 
tribute to  a lack  of  confidence  in  SACS  products  and  provide  a "crutch" 
when  either  PERSACS  or  LOGSACS  fails  to  support  a current  action.  Be- 
cause of  this,  the  users  of  SACS  data  are  not  as  aggressive  as  they 
otherwise  might  be  in  reporting  problems  of  a specific  nature  regarding 
either  PERSACS  or  LOGSACS  data. 
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SECTION  5 
RECOMMENDATIONS 


The  following  recommendations  of  the  SACS  Project  Team  on  the  study 
of  accuracy  and  timeliness  of  data  are  numbered  to  correspond  to  the  con- 
clusions in  Section  4. 

1.  Implement  a training  program  for  appropriate  personnel  at  all 
levels  of  ARSTAF,  supporting  organizational  entities,  USAMSSA,  and  users 
to  assure  awareness  of  the  overall  importance  of  SACS.  An  ongoing 
training  program  is  required  to  assure  that  newly  assigned  persons  are 
properly  aware  of  the  pervasiveness  of  SACS. 

2.  Align  the  update  frequency  of  all  SACS  supporting  systems  to 
coincide  with  the  MOC  window  within  TAADS.  Include  criteria  for  frequency 
of  EDATE  changes. 

3.  Implement  a policy  that  requires  all  input  data  be  subjected  to 
stringent  edit  criteria,  i.e.,  value,  compatibility,  syntax,  relationship, 
etc. 


4.  Implement  an  automated  SACS  data  audit  concept  that  will  account 
for  and  control  on  all  unit  records  extracted  from  FAS  (FSS,  FORDIMS)  and 
all  unit  detail  records  extracted  from  TAADS  (AS,  FORDIMS)  or  TOE  in  order 
to  ensure  that  SACS  products  properly  represent  the  M Force  as  selected 

by  SACS  criteria. 

5.  Develop  and  implement  automated  and  manual  procedures  for  a SACS 
configuration  control  concept  that  would  require  formal  reports  of  erron- 
eous SACS  data  or  processing  for  investigation,  validation,  and  implemen- 
tation of  corrective  action,  as  appropriate  in  the  supporting  system, 
either  by  way  of  updating  data  or  a systems  change  request. 

6.  Incorporate  BOIP  and  SHN  data  into  the  PERSACS. 


7.  Publish  a SACS  coordinated  Data  Management  Plan  (to  include 
quality  control  procedures),  an  updated  SACS  Data  Element  Directory, 
a SACS  systems  Procedures  Manual,  and  a SACS  Functional  Users  Guide. 

8.  Establish,  through  further  study,  the  most  appropriate  source 
of  authorization  and  requirements  data  for  each  use  currently  being 
made  of  SACS  outputs. 

The  above  recommendations  are  provided  for  preliminary  review  by 
the  Army  at  this  time  and  will  be  considered  during  pursuit  of  subse- 
quent study  tasks  leading  to  development  of  final  recommendations  for 
SACS  improvements. 
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PROBLEM  STATEMENT:  There  is  a general  lack  of  understanding  or  a 
misunderstanding  of  the  current  SACS  role  in  the  management  and  utiliza- 
tion of  force  structure,  personnel,  and  equipment  information. 

EXPLANATION /CAUSATIVE  FACTORS:  Current  SACS  is  used  more  compre- 
hensively than  it  was  5 years  ago.  Today  the  ARSTAF  and  field  activities 
are  using  SACS  data  to  a much  greater  degree  and  are  more  aware  of  SACS 
data  and  its  importance  and  shortfalls.  Despite  this,  there  is  no  uni- 
versal understanding  of  what  SACS  is  to  accomplish,  what  SACS  is  to  provide, 
and  what  degree  o$  importance  SACS  data  have  in  relationship  to  TAAVS, 

VTAAVS  or  TTAAVS  data.  In  addition,  there  is  minimal  understanding  o$ 
the  importance  ofi  SACS  data  within  the  organizational  entities  responsi- 
ble £cr  managing  data  which  are  critical  to  SACS.  This  condition  impacts 
the  quality  o$  SACS  data  firom  many  aspects.  SACS  data  convey  three 
fundamental  types  of  information  which  make  up  either  the  LOGSACS  or 
PERSACS  products.  These  types  of  information  are: 


• Organizational  data  described  by  major  commands, 
locations,  specific  unit  identifications,  and 
various  codes  for  administrative  purposes. 

• Personnel  data  described  by  aggregate  strengths 
by  military  identity  (officer,  warrant  officer, 
and  enlisted)  and  the  details  which  identify 
grade,  branch,  military  occupational  specialty 
(MOS),  and  quantity  related  to  each  specific 
unit  in  the  force  by  unit  identification  code 
(UIC) . 


i 


1' 


A- 2 


I, 


• Equipment  data  described  by  specific  type  of  equipment 
required  to  perform  the  specific  mission  of  the  parent 
unit  by  line  item  number  (LIN)  and  quantity. 

In  an  aggregate  form,  these  three  types  of  information  identify 
complete  MTOE  and  TDA  organizations  as  documented  in  the  DCSOPS  force 
structure  systems  and  are  categorized  as  "requirements"  and  "authoriza- 
tions" applicable  to  current,  budget,  and  program  years.  Each  unit  has 
one  or  more  effective  date(s)  (EDATE) , which  relates  to  unit  actions 
such  as  activations,  reorganizations,  deactivations,  etc.  The  EDATE 
is  used  for  phasing  units  through  the  force  and  is  subject  to  change  based 
on  the  requirements  of  force  or  command  managers,  MACOMS  (VFAS  or  VTAADS) 
or  the  equipment  modernization  program.  The  EDATE  can  be  changed  daily, 
weekly,  or  monthly  and  is  essentially  unconstrained.  For  example,  no 
rules  such  as  conditions  and  time-frames  for  changing  EDATES  have  been 
found.  Frequent  EDATE  changes  are  counterproductive  to  development  of 
timely  and  accurate  data,  since  they  introduce  turbulence  that  should 
not  be  permitted  to  influence  the  overall  force  structure  system. 

SACS  was  developed  in  the  1970  time  frame  as  the  ARSTAF  system  that 
would  provide  personnel  and  equipment  authorizations  data  to  the  principal 
ARSTAF  managers  of  personnel  and  equipment.  The  original  SACS  developers 
did  not  perceive  that  one  day  data  from  SACS  would  be  as  pervasive  as  it 
now  is  throughout  the  vast  Army  network  utilized  in  planning,  programming, 
and  budgeting;  in  the  personnel  functions  of  recruiting,  training,  promotion 
and  personnel  distribution;  and  in  the  materiel  functions  of  requirements 
computations,  war  reserve  planning,  equipment  distribution  and  transportation 
planning,  phased  equipment  modernization,  and  many  other  associated  logistical 
functions . 


EDATE  may  be  prescribed  for  various  changes  such  as:  MOS,  AMSCO,  LIN, 
or  other  guidance.  Force  Managers  and  MACOMS  in  FAS,  VFAS,  and  TAADS 
may  change  EDATES.  EDATE  changes  are  not  always  coordinated  for  future 
application  (DF,  DAPC-EPS-D,  18  October  1978,  "Identification  of  PERSACS 
Problem  Areas"). 


The  LOGSACS  utilizes  Basis  of  Issue  Plan  (BOIP)  data  whereas  PERSACS 
does  not.  The  BOIP  permits  the  application  of  equipment  modernization  data 
to  LOGSACS  whereas  the  Qualitative  and  Quantitative  Personnel  Requirements 
Information  (QQPRI) , which  is  included  in  the  BOIP,  and  applicable  to 
equipment  modernization,  is  not  applied  to  personnel  MOS,  grade,  branch, 
and  quantity  data  by  SRC  in  PERSACS  processing.  The  Army  recognizes 
that  BOIP  data  must  be  applied  to  PERSACS  and  once  this  is  accomplished 
the  PERSACS  will  provide  phased  authorizations.  This  will  not  be  pos- 
sible, however,  without  further  system  modification.  The  BOIP  is 
oriented  to  standard  requirements  code  (SRC)  and  each  BOIP  has  an  EDATE 
which  identifies  when  the  BOIP  is  to  be  applied  to  change  unit  XZqatXZ- 
me.nti.  Thus,  all  MTOE  units  organized  under  a particular  SRC  (may  be  one 
or  many)  have  the  BOIP  applied  with  a common  effective  date,  independent 
of  projected  phase-in  of  equipment.  Therefore,  the  function  of  "phasing" 
the  equipment  and  personnel  into  units  is,  in  reality,  the  function  of 
projecting  authorizations  which  is  controlled  by  "asset  availability 
projections. " 


A general  belief  exists  among  ARSTAF  personnel  that  the  unit  EDATE 
and  the  SRC  EDATE  are  applicable  to  the  phasing  of  both  requirements  and 
authorizations,  when  in  fact  these  dates  are  primarily  applicable  to 
requirements.  Only  the  dates  applicable  to  authorizations  are  controlled 
by  programming  and  budgeting  constraints  which  determine  asset  availability. 
These  realities  also  determines  when  units  are  to  be  provided  equipment  and 
personnel  from  "modernization  programs." 

The  current  SACS  is  accepted  in  some  quarters  as  the  authoritative 
source  for  requirements  and  authorizations  data.  However,  there  is  still 
significant  reliance  on  HQDA  TAADS  and  VTAADS  as  the  source  for  this 
data.  In  other  instances,  information  provided  by  installation  personnel 
is  accepted  as  the  source  for  requiremencs  and  authorizations.  U&ZM  0$ 
-teqcuA emeriti  and  authoAxzatiom  mat  ^xzqazntly  do  not  undzutand  the. 
imptcccutioni  0&  not  iititizinQ  SACS  da-ta..  SACS  is  always  unit  and  strength 
constrained  based  on  the  most  recently  approved  force  structure  and  manning 
levels.  No  other  requirements  and  authorizations  data  in  general  distribu- 
tion is  so  constrained. 
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PERSACS  data  are  used  very  extensively  throughout  MILPERCEN.  Their 
value  as  an  authorizations  base  is  extensively  questioned,  as  well. 
MILPERCEN  processes  PERSACS  data  in  its  authorizations  data  base  (AUDB) 
and  in  its  enlisted  requisition  validation  (REQVAL)  system  and  fre- 
quently makes  comparisons  of  PERSACS,  AUDB,  and  REQVAL  results  only  to 
find  that  they  are  at  variance.  This  type  of  data  variance  is  related  to 
processing  and  not  to  PERSACS,  though  PERSACS  is  frequently  given  credit 
for  the  variance.  Part  of  the  PERSACS  problems  at  MILPERCEN  are  not  with 
PERSACS  data  but  with  the  method  of  processing  and  utilizing  PERSACS  data. 
In  essence,  because  PERSACS  requirements  and  authorizations  data  are  uti- 
lized in  most  MILPERCEN  functions,  all  problems  with  such  data  are 
immediately  related  to  PERSACS.  It  is  essential  that  MILPERCEN  require- 
ments and  authorizations  problems  be  researched  through  their  processes, 
programs,  and  systems  to  trace  the  problem  to  its  true  source.  Only 
through  this  method  will  true  PERSACS  problems  be  identified  and  other 
requirements  and  authorizations  data  problems  identified  with  whatever 
processing  is  at  fault. 

IMPACT : 

• The  general  lack  of  understanding  of  the  pervasive- 
ness and  importance  of  the  SACS  results  in  a lack 
of  attention  to  quality  control  and  cooperative 
management  of  all  supporting  systems. 

• The  general  lack  of  understanding  of  processes  by 
which  PERSACS  data  are  handled  cause  problems  to  be 
attributed  to  PERSACS  when  the  problem  may  be  in  the 
processing  logic  employed  by  another  system  in  utiliz- 
ing PERSACS  data. 

• Inaccurate  data  in  systems  that  provide  data  to  SACS 
are  magnified  in  both  the  LOGSACS  and  PERSACS. 

• Army  planning,  programming,  and  budgeting  which  is 
based  on  erroneous  data  can  have  devastating  and  long 
range  effects. 
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SUBJECT:  Data  Edits 

PROBLEM  STATEMENT:  SACS  has  no  data  value  edits  or  data  compati- 
bility edits. 

EXPLANATION/CAUSATIVE  FACTORS:  The  concept  designed  into  SACS 
is  that  all  data  will  correctly  interface;  that  all  data  values  are 
accurate;  and  that  all  data  values  relate  and  are  compatible  with  all 
other  data  values. 

Many  data  elements  passed  to  the  SACS  have  had  either  no  edit  or 
an  ineffective  edit  applied  in  the  system  that  has  primary  data  element 
responsibility.  Some  examples  are: 

• Category  Code.  SACS  obtains  this  code  from  FAS.  It 
identifies  MTOE  units  by  category  of  combat,  combat 
support,  or  combat  service  support.  This  code  field 
currently  has  as  many  blank  entries  as  coded  entries. 

Since  blanks  are  accepted,  minimal  confidence  can  be 
placed  in  coded  entries.  This  code  is  used  by  MILPERCEN. 

• Identity  Code.  SACS  obtains  this  code  from  TAADS.  TOE 
dote  not  contain  thii  code  and  it  is  poorly  maintained 

in  TAADS.  This  code  is  important  to  MILPERCEN  in  process- 
ing assignments  since  it  is  the  indicator  which  specifies 
requirements  and  authorizations  by  male,  female,  or  either. 

• Split  Unit  Indicator.  SACS  obtains  this  code  from  FAS. 

It  should  be  confirmed  in  FAS  through  monthly  interface 
with  the  Army  Operations  Center  (AOC)  systems.  This 
code  is  used  by  MILPERCEN  for  purposes  of  assignments 
and  reassignments,  and  by  DESCOM  for  distribution  of 
equipment.  The  split  unit  indicator  can  indicate  that 

a subunit  of  a parent  unit  is  at  a different  geographical 
location  from  that  of  the  parent  unit  or  that  a unit  has 
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split  functional  entities  at  the  same  location.  In 
FAS,  this  situation  should  be  handled  like  two  par- 
ent units  and  TAADS  documentation  must  be  similarly 
separated  because  of  the  geographical  location. 

TAADS  identifies  split  units  with  a $ sign.  Neither 
FAS  nor  TAADS  currently  document  geographically  split 
units  satisfactorily. 

• Standard  Requirements  Code.  SACS  obtains  this  code 
from  FAS  and  TAADS.  FAS  SRC  input  is  not  edited 
whereas  TAADS  SRC  field  input  is  edited.  When  FAS 
and  TAADS  comparison  results  in  a mismatch  and  the 
FAS  SRC  is  in  error,  the  unit  can  be  dropped  from  the 
SACS  computation.  Additionally,  BOIP  and  SHN  utilize 
SRC.  It  is  a critical  data  element  to  SACS  and  all 
force  structure  systems. 

The  examples  cited  above  represent  only  a partial  list. 

Many  data  elements  passed  to  the  SACS  have  relationship/compati- 
bility/supportability  values  when  utilized  in  analyzing  an  entire  record 
or  series  of  records.  Some  of  these  codes  are: 

★ 

• Administrative  Control  Code 

• Assignment 

• DA  Master  Priority  List 

• DA  Planning  Priority  List 

• Deployment  Package  Assignment 

• Deployment  Designation 

• Location  Code 

• Mobilization  Command  Assignment 

• Mobilization  Location  Code 

• Mobilization  Period 

• Mobilization  Station 


As  presently  coded  in  FAS,  it  conflicts  with  JCS  Pub.  1 and  6. 
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• Readiness  Objective  Code 

• Station  Code 

• Military  Occupational  Specialty 

• Grade 

These  codes  have  some  relationship  values  which  must  be  compatible  and 
supportive  in  order  for  each  record  to  be  completely  useable  in  both 
the  personnel  and  logistics  functions.  This  list  is  not  intended  to 
be  complete.  At  least  two  or  more  of  the  listed  codes  must  be  com- 
patible because  of  their  relationship.  Administrative  control,  for 
example,  must  be  compatible  with  assignment  and  either  DAMPL  or  DAPPL 
depending  on  the  effective  date.  Also,  deployment  package  assignment 
must  agree  with  administrative  control  code. 

IMPACT:  The  most  serious  impact  of  the  hbsence  of  positive  data 
value  and  compatibility  edits  is  the  errosion  of  confidence  in  and 
creditability  of  SACS  products.  This  feeling  causes  users  to  design 
edit  procedures  into  their  systems  to  identify  SACS  data  errors  and 
time  and  effort  are  expended  to  correct  these  errors  before  continuing 
with  the  intended  use  of  the  SACS  products.  In  many  cases  where  incom- 
patibilities of  data  are  identified,  SACS  users  have  no  way  of  identify- 
ing the  incorrect  data  and,  therefore,  all  data  in  the  record  is  suspect. 
In  other  instances,  where  corrections  can  be  made,  an  inordinate  amount 
of  time  is  utilized  to  make  corrections. ^ 

In  other  cases  where  errors  are  identified  and  the  user  has  no  way 
of  correcting  the  error,  the  user  will  use  other  sources  of  requirements 
and  authorization  data.  Comparisons  to  other  sources  which  are  as  of 
different  dates  and  produced  for  significantly  different  purposes  result 
in  attempts  to  validate  SACS  data  with  noncomparable  data.  Also,  because 
the  TAADS  system  is  well  known  and,  because  it  is  generally  readily 


^This  was  reported  by  MILPERCEN,  RDAISA,  and  DESCOM.  One  MILPERCEN 
employee  stated  that  it  usually  takes  five  work  days  to  correct  PERSACS. 
DESCOM  cited  a specific  figure  of  64  hours  required  to  correct  LOGSACS. 
RDAISA  was  unable  to  provide  a specific  estimate  of  amount  of  time 
consumed. 
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available,  SACS  users  use  it  as  a validation  tool.  Since  Lndlvldual 
TAAVS  xe.pcx.tb  do  net  xepxebent  the  total  Wabtex  Fcxce  which  Lb  xepxe- 
bented  In  the  SACS  pxoductb,  thLb  Lb  atbo  noncompaxable  data. 


The  end  result  is  that  a significant  amount  of  manpower  and  systems 
resources  are  wasted  at  many  activities  in  identifying  and  correcting 
errors  which  should  have  been  corrected  in  a related  system  prior  to 
the  SACS  processing. 
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SUBJECT:  Data  Audits 

PROBLEM  STATEMENT:  LOGSACS  and  PERSACS  are  frequently  incomplete 
in  that  some  units  or  personnel  and/or  equipment  detail  data  may  not  be 
included. 

EXPLANATION/ CAUSATIVE  FACTORS:  There  is  no  current  quality  control 
technique  to  provide  assurance  that  all  units  and  their  applicable  detail 
are  included  in  SACS  outputs.  Therefore,  ODCSOPS  (DAMO-FDA)  frequently 
releases  SACS  outputs  only  to  be  subsequently  advised  by  SACS  users 
that  they  are  incomplete. 

Units  that  are  recorded  in  FAS,  to  which  SACS  "force  selection 
criteria"  are  applicable,  should  be  completely  represented  in  SACS 
output  by  data  which  describes  the  unit,  its  personnel,  and  its  equip- 
ment for  all  time  periods  reflected  in  the  FAS.  Under  current  SACS 
processing,  entire  units  or  personnel  and/or  equipment  detail  may  be 
omitted  from  SACS  products  because  the  unit  detail  is  not  available 
in  TAADS. 

Current  ODCSOPS  (DAMQ-FDA)  procedures  include  the  use  of  automated 
programs  (PAAS  and  BOIMARS)  to  evaluate  the  principal  SACS  products. 

These  programs  serve  their  intended  purpose  to  evaluate  and  analyze 
some  aspects  of  the  SACS  outputs.  The  shortcoming  of  these  programs 
is  that  they  do  not  carry  their  evaluation  and  analysis  far  enough  to 
assure  that  all  units  that  should  be  included  in  a SACS  run  are,  in 
fact,  included  in  the  output,  and  that  for  those  units  the  personnel 
and  equipment  detail  are  present. 

IMPACT:  Data  omissions  cause  delay  in  the  systems  that  utilize  SACS 
data  and  require  that  SACS  users  have  a data  correction  capability  built 
into  their  systems.  The  rerunning  of  SACS  is  sometimes  required.  In 


I 

I 

instances  where  data  omissions  are  not  detected,  entire  computation 

T 

processes  may  be  completed  in  error. 

M 

More  importantly,  logistics  and  personnel  functional  managers  use 
SACS  data/ reports  not  realizing  that  all  the  units  representing  the 
Master  Force  are  not  included  in  the  output.  This  can  cause  significant 
shortfalls  in  the  acquisition  and  distribution  of  equipment  and  personnel. 
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SUBJECT:  Feedback/Corrective  Mechanism 

PROBLEM  STATEMENT:  SACS,  FAS,  TAADS , and  TOE  are  independent 
systems.  They  do  not  have  feedback,  corrective,  or  interfacing 
mechanisms  for  resolving  erroneous  data  conditions. 

EXPLANATION/ CAUSATIVE  FACTORS:  SACS  does  not  have  the  capability 
to  perform  data  corrections  within  its  processing  cycle.  The  FAS,  TAADS, 
and  TOE  have  the  capability  to  correct  data  within  their  respective 
operations.  However,  the  operating  parameters  of  each  of  these  systems 
are  independent  of  each  other  and  erroneous  conditions  between  rhe 
systems  are  not  easily  resolved  because  of  different  processing  time 
sequences  and  different/various  organizational  origins  within  ARSTAF 
and  field  commands. 

Erroneous  data  conditions  in  single  systems  are  not  easily  corrected 
because  of  the  various  documents  chat  can  be  in  float  at  any  point  in 
time.  Multiple  FAS  transactions  for  a single  UIC  may  be  in  float  simul- 
taneously. These  transactions  may  be  originated  by  Force  or  Command 
Manager,  AUTS,  SIGMA,  or  VFAS  (command  plan  or  troop  list).  While  FAS 
transactions  are  in  float,  other  system  transactions  continue  to  flow 
on  their  schedule.  As  some  errors  are  corrected  others  are  developed. 

In  some  instances  it  takes  two  or  more  SACS  cycles  to  complete  correc- 
tions. Current  system  operating  concepts  require  too  much  time  to 
correct  erroneous  data. 

Once  SACS  Branch  personnel  (DAMO-FDA)  or  SACS  product  users  identify 
data  errors  or  problems,  they  have  no  established  correction  mechanism  at 
their  disposal.  The  SACS  Branch  personnel  are  responsible  for  SACS  data, 
yet  there  is  no  procedure  available  to  them  for  correcting  or  influencing 
day-to-day  force  structure  systems  data  maintenance.  The  current  practice 
is  that  SACS  Branch  personnel  coordinate  with  the  appropriate  functional 
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personnel  to  correct  data  problems.  The  SACS  data  users,  however,  in 
some  cases  have  built  into  their  systems  the  capability  to  correct  SACS 
data.  Frequently,  users  of  SACS  products  correct  data  from  one  run 
with  hope  that  the  data  will  be  correct  on  the  next  SACS.  Upon  receipt 
of  the  next  SACS,  the  same  errors  are  often  still  not  corrected 
because  there  is  no  procedure  for  these  errors,  or  their  corrections, 
to  be  fed  back  to  the  appropriate  systems. 


IMPACT:  SACS  data  users  devote  scarce  resources  to  correcting 
SACS  data.  Although  the  time  spent  is  justifiable  for  the  individual 
user  to  be  effective  in  performing  his  function,  there  is  no  procedure 
to  share  the  correction  with  other  users.  Even  more  significant  is 
the  fact  that  there  is  no  procedure  to  feed  the  correction  back  to 
SACS  so  that  subsequent  SACS  products  will  reflect  the  correct  data. 
This  continual  requirement  to  identify  and  correct  errors  only  serves 
to  exacerbate  the  lack  of  creditability  of  SACS  products. 
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SUBJECT:  BO IP  and  SHN  in  PERSACS 

PROBLEM  STATEMENT:  The  absence  of  BO IP  and  SHN  application  in 
PERSACS  creates  a fundamental  difference  in  the  quality  of  data  be- 
tween the  LOGSACS  and  PERSACS. 

EXPLANATION/CAUSATIVE  FACTORS:  The  BOIP  and  SHN  apply  to  the 
introduction  of  new  equipment  into  units,  the  refinement  of  unit 
detail  data,  and  the  insertion  of  unit  detail  when  it  is  not  avail- 
able from  either  TAADS  or  TOE.  The  absence  of  the  use  of  BOIP  in 
PERSACS  means  that  the  personnel  data  applicable  to  new  equipment 
are  not  automatically  reflected  in  SACS  although  BOIP  data  are 
reflected  in  LOGSACS. 

The  BOIP  does  include  equipment  modernization  data  such  as 
Qualitative  and  Quantitative  Personnel  Requirements  Information. 

This  QQPRI  is  reflected  in  the  BOIP  for  the  applicable  SRC  by  MOS, 
branch,  grade,  and  plus  and/or  minus  quantity.  Since  PERSACS  does 
not  include  BOIP  data,  MILPERCEN  personnel  must  attempt  to  manually 
change  personnel  requirements  data,  based  on  their  understanding  of 
BOIP  information,  to  compensate  for  the  lack  of  the  application  of 
BOIP.  These  efforts  are  generally  inadequate  and  not  in  consonance 
with  the  application  of  BOIP  in  LOGSACS. 

The  SHN  are  used  in  LOGSACS  to  refine  LIN  data  or  to  add  LIN  data. 
The  absence  of  a similar  capability  for  PERSACS  to  modify  personnel  data 
means  that  some  units  have  less  accurate  personnel  detail  and  some 
units  have  no  personnel  detail.  Either  situation  is  unsatisfactory 
as  all  units  and  their  respective  detail  data  must  be  reflected  as 
accurately  as  possible  in  both  LOGSACS  and  PERSACS. 
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IMPACT:  Some  new  systems  equipment  and  personnel  requirements 
and  authorizations  are  not  included  in  SACS.  MILPERCEN  is  forced 
to  rely  on  data  collected  via  "stubby  pencil"  or  on  data  obtained 
from  other  sources  as  the  information  necessary  to  support  recruit- 
ing and  training  requirements  for  the  equipment  modernization 
programs . 

A great  amount  of  manpower  is  consumed  in  locating  and  applying 
"informal"  information  to  PERSACS  where  a void  exists  because  BOIP 
and  SHN  are  not  applied  to  PERSACS  during  initial  processing. 
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SUBJECT:  Data  Management 

PROBLEM  STATEMENT:  Responsibility  for  data,  file,  and  consolidated 
system  management  is  fragmented  and  inadequate. 

EXPLANATION/CAUSATIVE  FACTORS : The  data  extracted  from  supporting 
systems  by  the  SACS  processes  for  inclusion  in  the  LOGSACS  and  PERSACS 
products  contain  numerous  errors  and  omissions.  This  is  primarily  due 
to  a lack  of  adequate  data  management.  SACS  extracts  data  from  five 
supporting  systems:  FAS,  TAADS,  TOE,  BOIP,  and  SHN.  Each  of  these  sys- 
tems has  data  management  procedures  which  may  be  adequate  for  their  indi- 
vidual purposes;  however,  cumulatively  the  data  management  is  inadequate 
for  SACS  purposes.  The  data  is  not  being  managed  with  the  knowledge  of 
the  serious  impact  data  from  other  systems  have  on  the  overall  operation 
of  the  Army.  Another  aspect  is  the  lack  of  coordinated  data  management 
between  supporting  systems.  Table  F.l  lists  SACS  related  systems,  their 
update  frequency,  and  other  relevant  details.  For  SACS  purposes,  DAMO- 
FDA  is  responsible  for  LOGSACS  and  PERSACS  data  but  does  not  have  control 
over  data  inputs  to  feeder  systems. 

Some  examples  of  data  management  inadequacies  are  as  follows: 

• Identity  code  is  described  in  Appendix  B.  When  SACS  data 
are  extracted  from  TAADS  the  identity  code  is  included. 

When  TOE  data  are  used  in  SACS  the  identity  code  is  not 
included.  Currently,  approximately  45,000  identity  codes 
are  in  error  and  129  identity  codes  are  blank. 

• The  FAS  Note  file  is  established  each  year  by  adding  one 
out  year  to  the  M Force  as  a result  of  the  TAA.  From  this 
point  through  the  execution  year  little  attention  is  given 
the  FAS  Note  file  although  it  it>  important  to  SACS  tince  it 

utitized  {,ok  the.  automated  p^ocehi  catted  "SRS  At>*ejmbty." 
When  the  FAS  SRC  is  in  error,  a TAADS  matching  problem  is 


Consolidated  TOE  changes  are  Issued  during  Apr  and  Oct.  Updates  are  Issued  all  other  months, 
'sitorthand  notes  are  developed  for  each  UKJSACS  as  required. 


presented.  SRC  as  input  to  FAS  for  the  PROFA  (FORFA)  file 
is  not  edited.  The  SRC  in  the  FAS  Note  file  is  similarly 
not  edited  nor  is  the  FAS  Note  file  synchronized  with  the 
PROFA  file.  Also,  when  SRC  entries  in  PROFA  and  FAS  notes 
are  not  coordinated,  negative  personnel  and  equipment  require- 
ments are  frequently  generated. 

Grade  and  MOS  changes  are  mostly  initiated  at  unit,  installa- 
tion, or  commands  rather  than  at  HODA.  Most  of  these  changes 
are  MACOM  approved,  which  means  that  requisitions  may  be 
submitted  to  MILPERCEN  prior  to  TAADS  data  being  submitted 
to  HQDA  and  prior  to  SACS  providing  such  data  back  to  MILPERCEN 
for  requisition  validation.  Grade  and  MOS  changes  not  based 
on  increased  or  decreased  strengths  should  be  controlled  in  a 
cyclic  manner  from  HQDA. 

POMCUS  identification  is  the  third  position  of  ROBCO  for 
active  Army  units,  whereas  for  reserve  units,  the  note  refer- 
ence data  element  field  is  used  for  POMCUS  identification. 

Some  units  are  incorrectly  coded  while  many  active  Army  units 
have  blank  ROBCO.  POMCUS  identification  is  important. 

RDAISA  and  DESCOM  personnel  currently  spend  much  time  and 
effort  in  attempting  to  properly  identify  POMCUS  units  so 
that  processing  and  attendant  POMCUS  stockage  computations 
are  correct.  POMCUS  <.dznti  fit  cation  ihcutd  be  a LZ.paA.att  data 
ttrnznt  ana  cloi tty  managed. 

ADCON  is  defined  in  JCS  Publications  1 and  6 as  the  data 
element  for  the  unit  identification  code  of  the  senior  unit 
(HQ)  exercising  administrative  control  over  the  organization. 
The  Army  is  currently  using  the  mnemonic  ADCON  to  identify 
deployment  package  and  deployment  date.  The  ADCON  duplicates 
other  deployment  data  elements  in  FAS  such  as  ROBCO,  DEPLO, 
and  DPMNT,  and  some  of  the  mobilization  data.  In  some 
instances,  DAMPL  or  DAPPL,  as  currently  used  with  ADCON,  are 
incompatible  when  used  in  conjunction  with  assignment  and 
location  codes. 


SACS  documentation  is  outdated.  The  current  SACS  users' 


guide  contains  a data  element  dictionary,  but  it  is  outdated 
and  of  little  value.  Problems  that  cause  questions  to  be 
asked  are  frequently  unresolved  because  answers  such  as  "I 
don't  know,"  are  frequently  the  only  answer  available.  This 
is  in  part  because  of  frequent  turnover  of  personnel  and 
lack  of  complete  and  current  documentation. 

There  is  no  management  across  systems.  For  example,  the 
split  unit  code  is  frequently  in  error  or  not  properly  used, 
yet  it  is  a code  in  FAS,  TAADS,  and  AOC ' s UIS.  There  is  no 
positive  continuing  nterface  data  quality  assurance  program 
to  guarantee  accuracy  and  increase  user's  confidence  in  SACS 
data.  The  split  unit  indicator  is  important  to  both  equip- 
ment and  personnel  distribution  to  ensure  that  the  correct 
destinations  are  used  in  orders,  shipping  instructions,  etc. 

Data  flow  constraints,  because  of  the  90-day  MOC  window, 
apply  to  MACOM  submission  of  TAADS  data  to  HQDA.  This  data 
cor.  traint  does  not  similarly  apply  to  FAS,  VFAS,  and  issu- 
ance of  original  PBG  guidance  or  monthly  guidance  changes. 

The  MOC  constraint  is  somewhat  unrealistic  because  it  applies 
to  TAADS  data  flow  only,  and  to  no  other  data  flow  involving 
other  systems  that  feed  information  to  SACS.  The  MOC  constraints 
limit  TAADS  to  90-dav  submissions,  while  permitting  force 
structure  decisions  to  be  made  and  recorded  in  all  other 
systems  daily  or  "as  required."  Consequently,  during  two 
90-day  periods  each  year,  HQDA  is  not  provided  current  deci- 
sion data  on  how  units  are  documented  in  the  force.  The  MOC 
data  flow  restrictions  should  be  examined  with  a view  toward 
applying  some  type  of  uniform  flow  restriction  on  all 
force  structure  information. 


The  above  examples  of  data  inadequacies  make  the  ODCSOPS  force 
structure  systems  unwieldly  and  very  complex  to  manage.  It  is 
important  to  remember  that  the  systems  that  must  currently  interface  were 
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not  originally  designed  with  the  current  SACS  interface  requirements  in 
mind.  Therefore,  SACS  frequently  has  problems  putting  the  LOGSACS  and 
PERSACS  pieces  together  to  make  meaningful  products. 

Data  management  implies  control.  Control  from  the  SACS  viewpoint 
should  encompass  the  data  and  their  collection  and  processing  systems 
that  feed  the  SACS  processes  to  develop  the  PERSACS  and  LOGSACS  products. 
The  second  method  of  control  is  the  day-to-day  management  of  data  within 
the  related  manual  procedures  and  at  the  manual-automated  interface. 

This  is  as  much  a management  of  the  attitude  toward  quality  of  data 
as  it  is  a management  of  data. 

Another  dimension  is  the  managers  awareness  of  the  use  of  data  and 
the  requirements  for  its  high  quality.  Many  staff  members  and  managers 
are  "experts"  in  their  special  area  but  lack  the  comprehensive  under- 
standing of  the  pervasiveness  of  SACS.  There  must  be  an  understanding 
that  quality  control  efforts  are  not  just  impacting  the  individual  sys- 
tem, but  have  exceedingly  more  important  and  far  reaching  impacts  on  the 
entire  Army  from  Congressional  action  in  the  Army  budget  to  distribution 
of  personnel  and  equipment  to  a unit.  This  requires  a knowledge  of  and 
interest  in  the  total  SACS  which  is  not  now  being  demonstrated.  This 
lack  of  knowledge  impacts  negatively  on  data  management  and  the  products 
of  SACS.  There  is  no  overall  centrally  controlled  data  management  concept 
in  use  within  the  ARSTAF. 

IMPACT:  The  overall  impact  of  inadequate  data  management  is  unco- 
ordinated and,  in  some  cases,  unacceptable  and  unusable  outputs.  Lack  of 
control  leads  to  data  omissions  which  can  result  in  excessive  SACS  com- 
putation time.  Incompatibility  of  data  values  between  data  elements  in 
single  records  cause  confusion,  conflict,  and  effort  to  be  spent  to 
determine  which  values  are  correct.  Data  value  errors  corrected  in  one 
supporting  system  are  not  fed  to  the  other  systems  thereby  causing  dupli- 
cation of  effort.  The  data  flow  timing  restriction  (MOC)  is  applicable 
to  only  one  of  five  supporting  systems,  which  contributes  to  some  untime- 
liness. 
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SOURCE  OF  REQUIREMENTS  AND  AUTHORIZATION  DATA 
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SUBJECT:  Source  of  Requirements  and  Authorizations  Data 

PROBLEM  STATEMENT:  Requirements  and  authorizations  data  are  pro- 
vided to  the  ARSTAF  from  at  least  two  sources  and  to  field  activities 
from  three  or  more  sources. 

EXPLANATION /CAUSATIVE  FACTORS:  The  current  Army  practice  regarding 
the  source  of  "official"  requirements  and  authorization  data  is  not  com- 
pletely clear.  AR  310-49  makes  a clear  statement  that  TAADS  is  the 
source  of  documented  requirements  and  authorizations  data  for  personnel 
and  equipment  transactions.  However,  the  current  Army  practice  is  to 
utilize  SACS  products  for  requirements  and  authorizations  for  validating 
personnel  and  equipment  requisitions  and  for  other  purposes.  This  prac- 
tice is  appropriate,  since  SACS  provides  information  constrained  by  FAS 
units  and  strengths.  Requirements  and  authorizations  information,  however, 
are  provided  to  the  ARSTAF  and  field  activities  from  a number  of  other 
sources,  which  cause  confusion,  conflict  between  data,  and  erosion  of 
of  confidence  in  any  one  data  source. 

The  current  sources  of  requirements  and  authorizations  data  are: 

• LOGSACS  and  PERSACS  products 

• HQDA  TAADS  (constrained  by  FAS  UIC  and  EDATE) 

• MACOM  - VTAADS 

• Installations  - ITAADS 

• Units  - Unit  documents 

The  contents  of  LOGSACS  and  PERSACS  have  been  constrained  by 
resource  limitations  as  reflected  in  FAS.  Also,  the  LOCSACS  utilizes  the 
BO IP  and  SHN  note  information;  and,  in  the  reasonably  near  future  PERSACS 
should  be  changed  to  utilize  BOIP  and  SHN.  The  data  prepared  in  a SACS 
computation  represents  the  Army's  requirements  and  authorizations,  limi- 
tations, and  future  equipment  modernization  program.  These  last  two 
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aspects  are  critical  to  all  requirements  and  authorization®  users  for 
their  planning,  programming,  and  budgeting  actions,  if  not  current  actions. 

The  HQDA  TAADS  retrieval  data  base  is  established  three  times  each 
month  (on  the  10th,  20th,  and  30th)  for  report  preparation  purposes. 
Inclosure  G-l  is  a list  of  reports  that  are  prepared  on  an  "as  required" 
and/or  a recurring  basis  from  this  data  base.  This  "retrieval  data  base" 
is  extracted  from  the  Authorizations  Subsystem  (AS)  of  FORDIMS  and  con- 
strained by  matching  it  to  FAS  on  UIC  and  EDATE.  Mismatched  TAADS/FAS 
data  identified  in  this  process  restrict  the  TAADS  from  being  available 
in  the  TAADS  retrieval  data  base.  Despite  the  fact  that  this  data  base 
is  usually  incomplete  and  does  not  represent  the  same  data  picture,  at 
any  point  in  time,  as  the  SACS  products,  it  is  used  extensively  as  a 
source  for  many  reports  provided  to  the  ARSTAF  and  field  activities. 

The  MACOM  - VTAADS  is  utilized  as  a source  of  data  for  making  and 
defending  decisions.  The  MACOM  - VTAADS  and  VFAS  have  no  current  auto- 
mated interface;  therefore,  the  only  VTAADS  and  VFAS  exchange  of  data  is 
through  manual  means.  MACOMS  provide  requirements  and  authorizations 
data  to  HQDA  and  to  installations  and  units  through  VTAADS.  These  data 
are  frequently  at  variance  with  those  which  are  in  the  possession  of 
functional  users  of  requirements  and  authorizations  information  at 
MILPERCEN,  DESCOM,  and  RDAISA,  primarily  because  of  EDATE  timing  and  data 
flow  (MOC). 

Installations  and  units,  at  the  bottom  of  the  requirements  and 
authorizations  ladder,  must  make  the  system  work  for  them  because  as  the 
"bottom  line"  operators  they  must  perform  their  assigned  missions.  The 
requirements  and  authorizations  that  appear  on  the  latest  authorization 
document  (TAADS)  are  the  basis  for  the  unit  commander's  personnel  and 
equipment  requisitions,  regardless  of  the  applicable  time  period  as 
determined  by  an  EDATE.  Frequently,  even  at  the  bettom,  requirements 
and  authorizations  are  controversial  between  the  Force  Structure,  Person- 
nel Managers,  Logistical  Managers,  and  Unit  Personnel.  This  usually 
results  from  lack  of  coordinated  communications  and  other  implications 
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such  as  the  installation  systems  and  their  source  of  requirements  and 
authorizations  data. 

IMPACT:  Each  agency's  position  is  defended  using  "best  information 
available."  The  impact  of  not  "reading  off  the  same  sheet  of  music" 
is  conflict,  mistrust  of  "the  other  agency's  data"  and  a continual  effort 
for  each  agency  to  validate  data.*  Controversial  requirements  and 
authorizations  data  are  currently  resolved  by  acquiesing  to  unit-provided 
authorization  data  (right  or  wrong),  cancelling  the  requisition  or  delaying 
final  action  until  validation  of  authorization  is  received. 

Drawn  out  disagreements  on  requirements  and  authorization  data 
between  ARSTAF  and  MACOMS  cause  extensive  delays  and  confusion  at  MILPERCEN, 
DESCOM,  RDAISA,  and  other  agencies,  and  cause  turmoil  among  the  personnel 
assigned  to  the  functions  that  must  utilize  such  data. 


*One  senior  MILPERCEN  official  referred  to  the  process  of  attempting  to 
clarify  requirements  and  authorizations  data  as  like  "blind  flying." 
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APPENDIX  H 

SPECIFIC  PERSACS/LOGSACS  TIMELINESS  AND  ACCURACY  PROBLEMS 


APPENDIX  H 


SUBJECT:  Specific  PERSACS/LOGSACS  Timeliness  and  Accuracy 
Problems 

PROBLEM  STATEMENT:  PERSACS/LOGSACS  timeliness  and  accuracy  problems 
erode  confidence  in  SACS  data  and  detract  from  their  acceptance  and  use 
in  various  functional  systems  for  personnel  and  logistics  management. 

EXPLANATION/ CAUSATIVE  FACTORS:  Inclosure  H-l  is  a list  of  specific 
examples  of  timeliness  and  accuracy  problems  which  are  representative  of 
the  difficulties  that  users  are  experiencing  with  PERSACS  and  LOGSACS 
data  as  a result  of  items  cited  in  previous  appendixes.  The  twenty-six 
entries  primarily  pertain  to  the  October  1978  PERSACS  and  LOGSACS.  SACS 
products  from  other  time  periods  are  also  involved.  These  cited  problems 
are  typical  of  those  being  experienced  with  the  use  of  each  PERSACS  and 
LOGSACS . 

The  specific  problems  resulting  from  the  use  of  erroneous  LOGSACS 
and  PERSACS  data,  as  shown  by  the  attached  list  are  documented  problem 
areas.  Another  significant  problem  is  the  excessive  amount  of  time 
various  users  spend  in  validating  the  LOGSACS  and  PERSACS  data/ reports 
ptiioK  to  their  use.  This  problem  is  not  directly  documented  in  hours 
spent  in  "purifying"  SACS  data.  It  is,  however,  the  basic  cause  for 
dissatisfaction  such  as  was  expressed  in  a Memorandum  for  the  Director 
of  Personnel  Management  Systems,  Subject:  PERSACS  Problem  Areas — Informa- 
tion Memorandum,  dated  5 Dec  1978  from  the  Director  of  Enlisted  Personnel, 
MILPERCEN. 

In  interviews,  MILPERCEN  personnel  have  stated  that  from  15  to 
25 X of  their  time  is  spent  in  analyzing  SACS  reports,  validating  with 
other  data  sources  and  correcting  errors  pftioK  to  being  able  to  use  SACS 
reports.  This  frustration  was  uniformly  expressed  by  virtually  all 
MILPERCEN  personnel  interviewed  during  this  portion  of  the  study. 
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Another  impact  of  the  erosion  of  the  creditability  of  SACS  is 
the  development  and  operation  of  parallel  validating  systems — both 
manual  and  automated.  In  an  effort  to  assure  that  SACS  data  is  in 


fact  right,  staff  managers  request  additional  reports  from  other 
systems  and  develop  an  informal,  off-line,  manual  management  validation 
system  tailored  to  their  individual  needs.  The  cumulative  manhours 
expended  by  staff  managers  in  developing  individual  "informal"  valida- 
tion systems  is  obviously  quite  extensive.  MILPERCEN,  RDAISA,  and 
DESCOM  have  all  incorporated  procedures  in  their  automated  systems  to 
permit  alteration  of  SACS  data  for  correction  of  identified  omissions 
or  inaccuracies. 


A further  dimension  of  the  problem  of  accuracy  of  SACS  data  is 
that  staff  managers  tend  to  falsely  blame  all  inaccuracies  on  SACS. 

Major  agencies  receive  SACS  tapes  and  process  these  tapes  using 
their  in-house  management  information  systems.  These  systems  produce  a 
multitude  of  reports  and  also  have  on-line  retrieval  capabilities.  When 
staff  personnel  find  errors  in  these  reports,  they  have  a tendency  to 
place  the  blame  on  SACS  without  realizing  the  error  could  have  been 
developed  by  the  in-house  system. 

IMPACT:  User  confidence  in  SACS  products  has  deteriorated,  pri- 
marily because  of  data  inaccuracies  and  omissions. 
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Inclosure  II- 1 

INCIDENTS  OF  TIMELINESS  AND/ OR  ACCURACY  PROBLEMS  IN  SACS  DATA 
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SUBJECT:  FORDIMS  Contributions  to  SACS  Improvements 

PROBLEM  STATEMENT:  FORDIMS  is  being  developed  to  replace  AFP,  CBS, 
FAS,  and  HQDA  TAADS.  In  this  process  some  changes  have  been  made  in 
data  element  record  structures  and  processing  which  require  specific 
consideration  of  SACS  implications. 

EXPLANATION/CAUSATIVE  FACTORS: 

Background . The  following  previously  separate,  major  HQDA  manage- 
ment information  systems  (MIS)  are  being  integrated  to  form  FORDIMS: 

• The  Army  Force  Program  (AFP) , 

• The  Civilian  Budgeting  System  (CBS) , 

• The  Force  Accounting  System  (FAS) , and 

• The  HQDA  portion  of  the  Army  Authorization 
Document  System  (TAADS). 

FORDIMS  Objectives.  The  basic  objectives  of  FORDIMS  are  to: 

a.  Provide  more  accurate  and  timely  force  structure  and  manpower 
management  data  to  the  Army  Staff. 

b.  Automate  the  production  of  manpower  reports  and  maintenance  of 
manpower  records  previously  produced  and  maintained  manually  by  the  DA 
Staff. 

c.  Eliminate  the  redundancy  of  data  in  the  HQDA  force  structure 
and  manpower  management  data  base. 

d.  Provide  a means  for  maintaining  a logical  and  auditable  relation- 
ship among  force  structure  and  manpower  data  in  Program  Budget  Guidance, 
budget  exhibits,  the  FYDP,  the  Master  Force,  the  Manpower  Requirements 
Report,  and  authorization  documents. 

e.  Reduce  USAMSSA's  system  maintenance  requirements  by  providing 
greater  flexibility  for  system  modifications. 
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FORDIMS  Concepts.  The  approach  used  to  achieve  the  above  objectives 
was  to  integrate  four  existing  systems  (listed  above)  using  the  TOTAL 
data  base  management  system  (DBMS) . The  TOTAL  DBMS  provides  an  integrated 
capability  to  relate  data  between  files  so  that  update  transactions  and 
retrieval  logic  can  operate  across  file  boundaries.  Integration  helps 
reduce  redundancy  through  the  elimination  of  unnecessary  duplication 
of  data  elements.  From  the  functional  user's  standpoint,  FORDIMS  can  be 
viewed  as  a single  integrated  file  that  is  composed  of  three  separate 
subsystems.  Through  use  of  the  DBMS,  complex  interfile  relationships 
can  be  maintained,  allowing  for  flexible  retrievals  and  rapid  response 
to  user  ad  hoc  requests. 

The  AFP  and  CBS  systems  performed  closely  related  functions  and  have 
been  consolidated  into  one  logical  system.  However,  HQDA  TAADS,  FAS, 
and  the  consolidated  AFP/CBS  systems  have  their  own  unique  sets  of 
functional  requirements  and  functional  processes  to  support,  with  certain 
common  data  relationships  (and  related  functions)  existing  among  them. 
FORDIMS  integrates  these  four  systems  in  a DBMS  environment  as  three 
separate  subsystems,  using  the  capabilities  of  the  DBMS  to  establish 
their  logical  file  and  record  relationships.  The  subsystems  are: 

• The  Program/Budget  Subsystem  (P/BS) , which  will 
replace  the  Army  Force  Program  (AFP)  and  Civilian 
Budget  System  (C3S). 

• The  Force  Structure  Subsystem  (FSS) , which  will 
replace  the  Force  Accounting  System  (FAS) . 

• The  Authorization  Subsystem  (AS) , which  has  re- 
placed the  HQDA  portion  of  The  Army  Authorizations 
Document  System  (TAADS)  . 

The  AS  became  operational  in  September  1977.  The  P/BS  and  FSS  are 
scheduled  to  become  operational  by  the  end  of  calendar  year  1979. 

Discussion.  As  indicated  above,  two  of  the  three  subsystems  that 
constitute  FORDIMS  are  still  being  designed  and  developed.  Until  such 
time  as  all  aspects  of  these  subsystems  are  developed  and  implemented, 
their  precise  impact  on  the  capability  of  ODCSOPS  to  produce  the  PERSACS 
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and  LOGSACS  will  be  subject  to  conjecture.  At  this  point  in  time,  it 
appears  that  although  some  benefits  will  certainly  be  derived  from 
FORDIMS,  these  three  subsystems  will  not  provide  solutions  to  all 
existing  SACS  problems,  and  in  some  instances,  they  may  create  some 
new  problems.  It  should  be  noted,  however,  that  FORDIMS  was  not  con- 
ceived as  a solution  for  all  that  is  wrong  with  SACS.  Indeed,  SACS 
was  not  mentioned  in  the  stated  FORDIMS  objectives  (see  above). 

From  the  SACS  user's  standpoint,  the  principal  sources  of  benefits 
that  can  reasonably  be  expected  to  be  derived  from  the  implementation 
of  FORDIMS  are: 

• Gutdancz  Tracking 

• Impnovzd  Accuao.cl/  o f VcUa 

• Improved  T-une£inzi&  of  Data. 

Although  each  of  these  sources  of  potential  SACS  benefits  is  discussed 
separately  below,  the  fact  that  these  three  areas  are  not  mutually  ex- 
clusive must  be  recognized  at  once.  For  example,  "Guidance  Tracking" 
should  contribute  to  both  "Improved  Accuracy  of  Data"  and  to  "Improved 
Timeliness  of  Data." 

Guidance  Tracking.  Guidance  tracking  is  the  process  of  establishing 
and  maintaining  an  audit  trail  which  will  enable  HQDA  to  identify  the  na- 
ture of  and  reasons  for  changes  in  Army  force  structure  and  manpower  from 
one  point  in  time  to  another,  and  to  verify  the  status  of  field  imple- 
mentation of  directed  changes  at  the  level  of  detail  necessary  to  satisfy 
HQDA  management  and  higher  authority  reporting  requirements.  This  includes 
accounting  for  changes  in  the  force  structure  as  well  as  changes  in  man- 
power authorizations  and  related  funding  data  by: 


• Reason  for  change  (e.g..  Program  Decision  Memorandum  (PDM) , 
Decision  Package  Set  (DPS),  headquarters  reduction,  tank 
conversion,  etc.) 

• Funding  classification  (Army  Management  Structure  code, 
program  element,  subprogram,  program,  appropriation,  and 
Defense  Planning  and  Programming  Category) 
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• Military/civilian  personnel  classification 

- Military  Identity  (officer,  warrant  officer,  and 
enlisted 

- Civilian  identity  (direct  hire  US,  direct  hire 
foreign  national,  and  indirect  hire) 

- Civilian  type  (e.g.,  US  Graded,  US  Wage  Grade,  etc.) 

• Organization  (Resource  Command  (RCOMD) , Major  Command/ 

Agency  (MACOM) , and  UIC) 

Guidance  Tracking  will  enable  the  ARSTAF  to  ensure  that  a logical 
relationship  exists  among  manpower  data  in  the  three  subsystems  of 
FORDIMS.  The  data  edits  and  compares,  associated  with  guidance  tracking, 
will  ensure  that  programmed  authorized  manpower  in  FICOD  F of  the  Master 
Force  in  the  FSS  plus  that  in  the  RCOMD  Management  Accounts  equals  that 
allocated  to  commands  and  recorded  in  the  P/BS.  These  edits  and  compares 
will  also  ensure  that  manpower  reflected  in  authorization  documents  in  the 
AS  equals  the  manpower  programmed  for  each  unit  in  the  FSS.  Thus,  it 
will  be  possible  to  determine  the  reasons  for  differences  between  the 
programmed  and  documented  strength  portions  of  a unit  and  HQDA  managers 
will  be  able  to  insist  upon  prompt  action  by  MACOMs  to  include  directed 
manpower  actions  in  their  Command  Plans  (and,  hence  in  the  Master  Force) 
and  in  their  authorization  documents.  Guidance  tracking  should,  there- 
fore, reduce  the  need  for  "assumptions"  on  the  part  of  force  managers 
as  to  how  the  MACOMs  will  spread  manpower  changes  to  units;  reduce  the 
number  of  differences  between  the  programmed  and  documented  positions 
for  a unit  for  which  there  are  no  known  reasons  at  HQDA,  and  therefore 
reduce  the  need  for  factoring.  Guidance  Tracking  will  provide  a capa- 
bility for  instilling  discipline  in  a system  that  is  presently  largely 
undisciplined.  However,  it  will  not  completely  eliminate  the  need  for 
factoring  because  the  latest  documented  manpower  position  for  a unit 
will  not  always  reflect  the  latest  programmed  position  for  that  unit. 

Improved  Accuracy  of  Data.  Improvements  in  the  accuracy  of  data 
obcained  from  FORDIMS  can  be  expected  to  result  from  several  aspects  of 
FORDIMS'  design,  as  follows: 
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• Improved  edits 

• Data  element  standardization 

• Use  of  the  TOTAL  DBMS 

• Derivative  benefits  of  guidance  tracking 

i.  !] 

Improved  Edits.  FORDIMS  has  increased  the  scope  of  data  element 
va£ue  zdLctb,  as  compared  to  existing  systems.  Some  syntax  and  rela- 
tionship edits  are  also  being  implemented.  However,  the  exact  edit 
programs  and  criteria  being  built  into  FORDIMS  are  currently  documented 
only  in  working  program  specifications. 

Value  edits  are  currently  being  programmed  for  the  following  data 
elements  in  one  or  more  FORDIMS  subsystems. 

FORDIMS 


Data  Element  Name 

Mnemonic 

Subsystem 

Army  Management  Structure  Code 

AMS  CO 

AS 

Army  Location  Code 

ARLOC 

FSS 

Branch  of  Service  Code 

BRNCH 

FSS 

DA  Master  Priority  List 

DAMPL 

FSS 

DA  Programing  Priority  List 

DAPPL 

FSS 

Force  Identification  Code 

FI  COD 

FSS 

General  Officer  Command 

GOCOM 

FSS 

Line  Item  Number 

LINUM 

AS 

Major  Command  Code 

MACOM 

FSS  and 

AS 

Major  US  Army  Reserve  Command 

MARCM 

FSS 

Military  Occupational  Specialty  Code 

MOSCO 

AS 

Resource  Command 

RCOMD 

FSS 

Subcommand  Code 

SBCOM 

FSS 

Standard  Requirements  Code 

SRCOD 

FSS  and 

AS 

Unit  Status  Code 

STATS 

FSS 

Unit  Identification  Code 

UICOD 

FSS  and 

AS 

Unit  Level  Code 

ULCCC 

FSS 
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Data  Element  Standardization.  Considerable  work  has  been  done  on  the 
standardization  of  data  elements  in  the  three  subsystems  of  FORDIMS. 

This  work  is  reflected  in  the  data  element  dictionaries  which  are  in- 
cluded in  each  volume  of  the  FORDIMS  User's  Guide  as  Appendix  F. 

Use  of  the  TOTAL  DBMS.  FORDIMS  files  are  being  linked,  stored, 
and,  in  part,  manipulated  by  the  TOTAL  data  base  management  system. 

This  should  improve  the  ease  of  handling  data  (input  and  retrieval)  and 
contribute  to  improved  data  accuracy  and  the  ease  of  producing  new  reports. 

Derivative  Benefits  of  Guidance  Tracking.  (See  discussion  of 
Guidance  Tracking,  above.)  FORDIMS  will  provide,  for  the  first  time,  a 
means  for  ensuring  that  the  manpower  allocated  to  commands  is  the  same 
as  that  reflected  in  the  Army  Master  Force  and  in  MTOE  and  TDA  authori- 
zation documents. 


Improved  Timeliness  of  Data.  Expected  improvements  in  the  timeli- 
ness of  data  output  by  FORDIMS  depend  greatly  on  anticipated  improvements 
in  HQDA  management  capabilities  as  a result  of  Guidance  Tracking.  Deter- 
mination of  the  extent  to  which  these  improvements  will  actually  be 
realized  must,  of  course,  await  the  full  implementation  of  FORDIMS  and 
Guidance  Tracking.  However,  FORDIMS  will  provide  a means  to  check  on 
the  progress  of  implementation  of  manpower  guidance.  If  MACOMs  are  late 
in  reflecting  guidance  in  their  VFAS  Command  Plan  submissions  and/or 
in  documenting  guidance  in  their  VTAADS  submissions,  that  tardiness  will 
be  apparent  in  FORDIMS  reports  and  HQDA  managers  can  take  appropriate 
action 

Continuing  Problems.  Existing  problems  (of  the  current  systems) 
which  will  either  not  be  greatly  affected  or  will  not  be  affected  at 
all  by  the  implementation  of  FORDIMS  are  outlined  below: 

• Input  scheduling.  Daily  HQDA  updates  of  Force  Structure 
Subsystem  data  will  continue  with  monthly  VFAS  exchanges 
of  MACOM  data  as  FSS  input.  The  twice  yearly  MOC  90-day 
window  will  remain  unchanged  for  VTAADS  input  to  the  AS. 

No  significant  changes  in  the  flow  of  other  data  are 
anticipated. 
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• Factoring.  Some  factoring  will  still  be  required  (see 
above) . 

• Data  management.  Although  responsibilities  for  specific 
data  elements  are  being  assigned  to  specific  ARSTAF 
divisions,  some  data  elements  are,  of  necessity,  assigned 

to  two  or  more  divisions.  Thus,  current  ARSTAF  data  manage- 
ment problems  can  be  expected  to  continue. 

• Edits.  In  establishing  the  initial  FSS  data  base  from  FAS, 
an  edit  table  which  relates  UICOD/COMPO/RCOMD/MACOM/SBCOM 
will  be  employed.  Thereafter,  however,  it  will  not  be  used. 
The  accuracy  of  those  data  elements  relating  together  will 
be  the  responsibility  of  the  data  element  proponent,  at 
time  of  input,  as  specified  in  the  FSS  User's  Guide.  FSS 
and  AS  do  not  have  specific  compatibility  edits  of  rela- 
tionship values  for  these  or  other  data  elements.  There 
will  also  be  no  edit  to  ensure  the  correct  relationship 
between  ADCON  and  DAMPL/DAPPL,  nor  will  there  be  an  edit  to 
ensure  that  unit  ADCON  changes  follow  logical  progression. 
FORDIMS  will  not  edit  POMCUS  unit  identification  for  con- 
sistency over  time  to  ensure  that  the  same  unit(s)  does  not 
fluctuate  in  and  out  of  POMCUS  status  within  short  time 
periods  (reported  by  DESCOM  as  a problem  with  the  LOGSACS 
provided  on  15  December  1978).^" 

It  should  be  noted  that  none  of  the  edits  suggested  above  are  in 
current  systems,  and  HQDA  functional  users  have  not  requested  such  edits 
nor  established  the  necessary  criteria/ relationships  to  allow  them  to  be 
programed  in  FORDIMS. 

Potential  New  Problems.  At  this  point  in  time,  inasmuch  as  FORDIMS 
has  not  been  completely  developed  and  implemented,  the  identification  of 
possible  new  problems  is  largely  a matter  of  conjecture.  However,  the 
following  appear  to  be  potential  problem  areas: 

^FACTSHEET,  26  December  1978,  DRSDS-LDD,  paragraph  2b. 
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• Software . The  USAMSSA  SACS  programs  to  freeze  and 
load  files  must  be  changed  to  function  with  P/BS  and 
AS  formats  or  the  P/BS  and  AS  formatted  data  must  be 
converted  to  FAS  and  TAADS  formats. 

- SIGMA  programs  function  with  FAS,  TAADS,  and  TOE 
formats.  A similar  conversion  problem  exists. 

- SACS  programs  will  not  function  with  FSS  and  AS 
formats.  A similar  conversion  problem  exists. 

- New  programs  may  be  required  to  select  and  merge 
FICOD  F and  P records. 

• Conversion.  Since  the  aforementioned  software  has 
not  been  modified  to  utilize  the  FSS  and  AS  formats, 
data  conversion  from  FSS  and  AS  formats  to  FAS  and  TAADS 
formats  is  required.  In  this  conversion  process,  it  is 
likely  that  turbulence  will  be  introduced.  A case  in 
point  was  the  omission  of  detail  data  for  some  units  in 
the  October  1978  LOGSACS  and  PERSACS  which  was  traced 
to  the  AS  conversion  to  TAADS  format. 

• Force  Selection.  Under  FORDIMS , the  Master  Force  will 
be  composed  of  FICOD  F,  the  "resources"  force,  and 
FICOD  P,  the  planned  force.  The  Master  Force  will  consist 
of  FICOD  F,  except  where  FICOD  P data  exists,  in  which 
case  it  will  overlay  FICOD  F data  in  the  Master  Force. 

This  interjects  the  possibility  of  (a)  confusion  in 
selecting  the  SACS  Force,  and  (b)  of  total  PERSACS 
manpower  and  equipment  requirements  that  exceed  OSD  and 
Congressional  constraints,  since  FICOD  P will  not  be 
"resources." 

The  foregoing  statements  are  considered  to  be  conservative,  but  generally 
identify  the  areas  in  which  problems  can  be  anticipated  during  the  complete 
conversion  to  FORDIMS  software  and  data. 
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IMPACT:  SACS  will  experience  turbulence  during  the  conversion  from 
FAS  and  TAADS  to  FORDIMS  software  and  data.  SACS  processing  will  require 
close  scrutiny  during  and  after  conversion  to  FORDIMS.  Data  timeliness 
and  accuracy  should  not  deteriorate  significantly  during  the  conversion 
period.  Subsequent  to  the  conversation  period,  the  quality  of  SACS  data 
may  be  expected  to  improve  to  some  extent,  however,  major  improvements 
in  SACS  processes  and  software  will  be  needed  if  DA  timeliness  and 
accuracy  objectives  are  to  be  met. 
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